Accessing Microsoft Dynamics GP Default Settings from Visual Studio Tools

Rarely you will hear the Dex.ini file being called the Microsoft Dynamics GP defaults file. However, the Dex.ini contains keys (and their associated values) that define how Microsoft Dynamics GP behaves in some cases. For example, SQLLastUser=sa stores the login of the last user who accessed the system on that specific instance of Microsoft Dynamics GP, in this case, 'sa'. Likewise, AutoInstallChunks=TRUE, allows Microsoft Dynamics GP to bypass prompting the user for new code (chunk file) to be installed at the time of launching the application. There are other settings controlling how certain features behave.

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();
MessageBox.Show(strPath);

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:

GetDexIniSetting function

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.

// Created by Mariano Gomez, MVP
// This code is licensed under the Creative Commons 
// Attribution-NonCommercial-ShareAlike 3.0 Unported License.
// http://creativecommons.org/licenses/by-nc-sa/3.0/legalcode

public string GetDexIniSetting(string searchKey)
{
   ParameterHandlerClass myParamHandler = new ParameterHandlerClass();
            
   try
   { Dynamics.Application gpApp = (Dynamics.Application)Activator.CreateInstance(Type.GetTypeFromProgID("Dynamics.Application"));
     if (gpApp == null) 
       return "";
     else
     {
       string passthrough_code = "";
       string compile_err;
       int error_code, result;

       result = gpApp.SetParamHandler(myParamHandler);
       myParamHandler.IN_Key = searchKey;

       passthrough_code += "local boolean err_val;";
       passthrough_code += "local string dex_key_val, dex_key;";
       passthrough_code += @"err_val = OLE_GetProperty(""IN_Key"", dex_key); "; 
       passthrough_code += "dex_key_val = Defaults_Read(dex_key);";
       passthrough_code += @"err_val = OLE_SetProperty(""OUT_KeyVal"", dex_key_val);";

       gpApp.CurrentProductID = 0; 

       error_code = gpApp.ExecuteSanscript(passthrough_code, out compile_err);
       return myParamHandler.OUT_KeyVal;
     }
   }
   catch
   { MessageBox.Show("Failed to initialize gpApp");
     return "";
   }
 }

public class ParameterHandlerClass
{
  public string IN_Key { get; set; }
  public string OUT_KeyVal { get; set; }
}

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.

That's it!

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.

[DllImport("kernel32.dll", CharSet = CharSet.Unicode)]
 static extern uint GetPrivateProfileString(
 string lpAppName,
 string lpKeyName,
 string lpDefault,
 StringBuilder lpReturnedString,
 uint nSize,
 string lpFileName);

//get path which should be the addins folder
String strPath = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);

//look for \Addins path
if (strPath.EndsWith(@"\AddIns", true, System.Globalization.CultureInfo.InvariantCulture) == true)
{ //and if we find one replace with the data folder
  strPath = strPath.Replace(@"\Addins", @"\Data\Dex.ini");
}
else
{ //if not in addins then we must be in the root GP folder (like GP 2013 does with GP addins) so tack on \Data
  strPath = strPath + @"\Data\Dex.ini";
}
 
StringBuilder sb = new StringBuilder(100);
uint res = GetPrivateProfileString("General", "Pathname", "", sb, (uint)sb.Capacity, strPath);
MessageBox.Show(sb.ToString());

// Copyright © Microsoft Corporation.  All Rights Reserved.
// This code released under the terms of the 
// Microsoft Public License (MS-PL, http://opensource.org/licenses/ms-pl.html.)

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!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/