In doing some digging, I remembered a few Dex.ini settings that control whether the Microsoft Dynamics GP desktop shows maximized upon start up and the position at which the desktop appears. So, I took my good ol' friend Notepad and edited the DEX.INI to find the following:
|Sample DEX.INI entries|
As you can imagine, this problem can be easily replicated if you have a dual monitor and move the GP desktop off to a second monitor or by reducing the desktop size and moving the window off screen.
The fix is also pretty simple indeed. Reset the WindowMax key value to TRUE and bring the WindowPosX and WindowPosY key values back to some manageable parameter values, for example 150 and 150. End of the problem, right? Not quite.
The client then requested to put the proper controls in place to prevent this from happening in the future. In some environments where I have been, system administrators have simply decided to make the Dex.ini file read only to avoid any changes being written to the file. However, as my good friend David Musgrave over at Developing for Dynamics GP explains in his article Why making the Dex.ini file read only is evil, this is not such a good idea as it can cause a number of headaches given the dependency Microsoft Dynamics GP has on the key file.
Of course, here's where the Support Debugging Tool comes into play.
The Support Debugging Tool's Dex.ini Configuration feature allows a system administrator to manage individual key file settings at his/her discretion, with the ability to persist the key values for all Microsoft Dynamics GP clients and their respective Dex.ini file. There are 4 deployment scenarios where this can be very useful:
1. In a Server and Workstation(s) scenario, where the server and workstations each will have a copy of the Microsoft Dynamics GP client - hence, each workstation will have its own Dex.ini file.
2. In a Terminal Server or Citrix environment with a single instance of the Microsoft Dynamics GP client - hence a single Dex.ini file.
3. In a Terminal Server or Citrix environment with a single instance of the Microsoft Dynamics GP client, but multiple Dex.ini files, each stored at the user profile level.
4. In a load-balanced Terminal Server or Citrix environment where Microsoft Dynamics GP runs on each server participating in the farm - hence, each server will have its own Dex.ini file.
However, and in all cases for Dex.ini Configuration to work effectively, the Support Debugging Tool's Debugger.xml settings file must be shared (in a central location on the network) and reachable by all Microsoft Dynamics GP clients, regardless of the deployment method. To share the Debugger.xml, you must change the path to the file under the Dex.ini Settings option of the Support Debugging Tool as shown below:
|Support Debugging Tool's Dex.ini Settings window|
For more information on installing the Support Debugging Tool, see Installing the Support Debugging Tool for Microsoft Dynamics GP FAQ over at Developing for Dynamics GP.
You can then use the Dex.ini Configuration window to control the window size and position for all workstations as shown below:
|Support Debugging Tool's Dex.ini Configuration Window|
One more thing to keep in mind, is to set the Path Default Setting as indicated above to make sure all workstations inherit the same values automatically.
Now that you know how to avoid the headache, go an install the Support Debugging Tool and come to my MSDynamicsWorld Decisions Fall 2011 session on the subject.
Until next post!
Mariano Gomez, MVP