I'm working on an addin where in i have the requirement of getting the current active window in Dynamics GP. I'm using .net to create my plug in and below two assemblies.
How can I achieve same ?
Thanks in advance!
I think you will need to drop down to windows API to achieve that.
This code project page shows more than you need, I guess GetForegroundWindow() would do you, I expect you will need to do some research around that and mapping the windows you want to trigger your code from in GP.
I don't believe that is possible with standard Visual Studio Tools code. You will need to go low level to get the window in focus (as Tim says), then you can get the handle and the window title. However, getting back to technical name of the window itself will be difficult.
What are you trying to achieve? Understanding the bigger picture will help us suggest solutions.
Thanks Tim & David,
We have a legacy application in .net which use DexToNet (TamerSoft DexToNet) component to connect to dexterity. Now, we are converting it to use VS SDK instead. while migrating the existing code, We came across this requirement.
We have some logic in there which set the new form's location and size based on the size of the mdi client window of dex. like, if the new form's size is larger then the dex form, reduce it.
Hope this gives you more idea.
If you know the Dexterity window, then obtaining the information is easy. The issue is dynamically getting the current window.
Even in Dexterity there is no way to directly get the current window. The only method is to dynamically register triggers on the activate event of every window as it opens and get the trigger handler code to store the window name somewhere when the window gains focus.
I had not seen this component before. I can't immediately find an overview of what it is or does. From a forum post it looks like some kind of .NET interop into Dexterity?
As David said above, I think this will be challenging from the Visual Studio add in.
Perhaps there are clues from the existing code as to how that component achieves this. Do you have any method signatures? My guess would be that the component has a Dexterity side to it that has implemented functionality much as David describes.
So many years ago I also need to find the current active window information in dexterity and I did this with 2 different way. One was to create a function in dexterity to use COM objects and use GetDexActiveWindow().And second method was to use command prompt commands and use some batch files to get the Dynamics GP active window, which I don't know still work in with windows 8 or not.[ I tried to search that code in my backups but hopeless. :( , I think I must gather all the codes to some handy and save place so don't run like mad when need them ]
Anyway you can still use GetDexActiveWindow() to get the active window and do the needful.below are some helpful hints.
The GetDexActiveWindow() method returns 4 string parameters that tell us the Form technical name,window technical name, dictionary name and window title. Shown below is an example of this code:
Dim result As Boolean Dim mystr1 As String Dim mystr2 As String Dim mystr3 As String Dim mystr4 As String
result = eEnterpriseApp.GetDexActiveWindow(mystr1, mystr2, mystr3, mystr4)
MsgBox ("Form Name = " & mystr1) MsgBox ("Window Technical Name = " & mystr2) MsgBox ("Dictionary Name = " & mystr3) MsgBox ("Window Title = " & mystr4)
I am in a little hurry, just login to reply your question, sorry can't help much.
DexToNet is quite an old product, I remember having it's trial version on 2009. : )
Yes, this component is very old and no longer supported. And that's the reason we re moving to VST. I was going through Microsoft.Dexterify.Shell and found a class "Microsoft.Dexterity.Shell.DexForm" that has ActiveForm property.
Not sure if that will do it. tried but getting null. :)
Do you know if there is any documentation around Microsoft.Dexterity.Shell classes ?
I would give it a try with GetDexActiveWindow. Where can i get the reference for eEnterpriseApp.GetDexActiveWindow ?
Almas included the link to the script in her post
This is Dex script, so you would have to create a Dexterity modification to include this script, then exposing that Dex code to .NET.
That is a a good explanation of how to achieve it!
Wow. You never stop learning.
I had not seen that Continuum call before.
Good find Almas.
PS: Just be aware that using Continuum can have issues if more than one instance of Dynamics/Dexterity is running on a system. It always connects to the first instance and not necessarily the one you want.
You set a high bar with this one. Outstanding!!
What exactly your objective is?
The front most window is the active window, If you will open Sales Transaction Entry Window and then open customer Window from it and then from customer window will open Shipping Method window then the 'Shipping window' is the active window.
It seems you are coding something where you have to find which window is active and then on the basis of active window do some task.
Hany, the GetDexActiveWindow() method we are talking in this post can be used to find the active window name, it returns 4 string parameters that tell us the Form technical name, window technical name, dictionary name and window title. You can use it's in dexterity as well by adding com reference.
You are right David. Thanks for reminder.
Hany, other way is registering a trigger against dynamics GP function "Security" and then get resource id from it. I have done this before when needed to know current window name.
The method I use to track active windows (already using this in GP Power Tools), is triggering before the Security procedure (not the function) as the procedure is called automatically when windows open. The function is called when windows open AND at other times.
You can then register a cross dictionary trigger (so it can handle any product) on the Activate event of all windows in the form. You will need to store the dictionary, form, window and trigger tag details in a memory table.
When the trigger fires, use Trigger_GetCurrentTag() to get the tag, do a reverse lookup on the memory table to identify the dictionary, form and window and store those results in global variables.
Then you can look at the global variables to identify the last current window.
You will also need to look in the table to see if that dictionary, form, window is already in the table (and so has a trigger), before registering your trigger.
Do not make the mistake I originally made (but have now fixed), by unregistering the triggers when the form is closed. As this will cause the trigger tags to increment every time a window is opened and closed. This will eventually cause the trigger tags to exceed 32768 and go to -32767 and then go to 0 and start duplicating already used tag numbers. This caused all kinds of issues. So keep the triggers registered and use the table to avoid registering more than once.