You can find a list of Dex.ini settings here.
Recently, I was helping a good friend of mine up in Maine who attended my Dexterity class in Boston and this time he wanted to know how to read the path for the Microsoft Dynamics GP help file. Of course, there's a simple (predefined) method for this as my good friend Patrick Roth with the Escalation Engineering team in Fargo pointed out, if you are familiar with some of Microsoft Dynamics GP form procedures:
string strPath = "";
strPath = Dynamics.Forms.MainMenu.Functions.GetDynamicsHelpPath.Invoke();
So, let's assume you had no clue this function existed. How would you address this issue? Frankly, I can think of at least 3 ways to do this:
1) Using a hybrid method whereby you create a Dexterity dictionary to wrap the Defaults_Read() Dexterity sanScript function into a user-defined global function. This method presents a challenge as you need to use the Dictionary Assembly Generator (DAG.EXE) to create an assembly you can reference from your VST project. In addition, you may or may not want to add an entirely new dictionary into the picture, when delivering your final solution. However, in case you are interested, this is the implementation:
For more information on developing hybrid applications with Dexterity and Visual Studio Tools take a look at my articles:
Developing Microsoft Dynamics GP hybrid integrating applications
Hybrid development for the Managed Code developer
Hybrid development for the Managed Code developer (cont.)
2) You could use the Continuum API from Visual Studio Tools to access the Defaults_Read() sanScript function. The Continuum API is the Component Object Model (COM) API that is available for Microsoft Dynamics GP. The Continuum API documentation is available for download here. In this method, all you have to do is add a reference to the interop.Dynamics.dll COM library, which hosts the Continuum API.
In the above code, we define a parameter handler class with couple properties for the key that will be read from the Dex.ini and the key value to be retrieved.
In our GetDexIniSettings method, we instantiate our class and use the Continuum SetParaHandler() method to load the IN_Key property value. We then setup our pass-through code and invoke sanScript's OLE_GetProperty() function to retrieve the value of the IN_Key from our VST application via some old fashioned OLE automation. The OLE_SetProperty() function then returns the value to our class property, OUT_KeyVal.
3) The third method uses some classic C# reflection to get the path of the AddIns. It then converts this to the path of the Data folder and the dex.ini file, and then uses the Pinvoke() method to read the key in the dex.ini and return the value.
The above method comes courtesy of my good friend Patrick Roth with the Escalation Engineering team at Microsoft.
All the above methods are generic in nature and can read more than just a specific key. It's good to know that there's more than one way to do things. If you are going all hybrid, there's a code for that! If you want to be self-contained, there's a code for that! If you want to deviate completely from sanScript because you hate it or don't know it, there's a code for that! Whatever route you choose it must work to your benefit.
As a good Australian friend of mine would say, "The right solution is the one that works!".
Until next post!
Mariano Gomez, MVP