One of the great things about Dexterity is that you can develop complex customisations without needing access to the source code. Even if you have access to source code via the Source Code program, a Dexterity developer never actually changes original source code.
By using triggers before and/or after the original code, it is possible to change the behaviour of the original code or add additional functionality. Because we never changed source code directly, Dexterity customisations can be upgraded between versions of Microsoft Dynamics GP very quickly and often just need testing after upgrading.
Even though you cannot see the core functions and procedures in distributed Dynamics.dic (because the source code has been removed), you can still call (or trigger against) any of the form level or global level functions and procedures as long as you know the name and the parameters.
The same goes for 3rd party dictionaries. It is possible to call a form or global level function or procedure in a 3rd party dictionary if you know the name and the parameters. A procedure can be called with the call with name in dictionary command and a function can be called using the execute() function using pass through Dexterity sanScript. You can also use the Trigger_RegisterXXByName() series of function library commands to register cross dictionary triggers.
Please see the post Cross Dictionary Dexterity Development for more information on working with 3rd party dictionaries.
So how do we get the names and parameters?
The Software Development Kit (SDK) is the best source of information. The SDK can be installed from the Tools folder of CD 2 of the install CDs or downloaded using the links on the Developer Articles & Links page. Many of the common calls needed by developers are listed in the various Programmer’s Interface documents in the SDK. If the call is provided in this documentation, you will have details of all the parameters and what values should be set for each parameter as well as a description of what the call does.
In Dexterity Test Mode, you can use the Debug menu and Script Logging feature to capture existing core code calling the function or procedure in a script.log file. The script log shows the values of the parameters passed (except the contents of composite fields or table buffers). This would still provide a guideline to what information was passed and how many parameters there are. For example:
‘Messenger_Status’, “CUS”, “AARONFIT0001”, “PRIMARY”, 0, MessengerButton
To find out more information about the call you can look at the parameter documents in the SDK. For example the parameter information for Dynamics.dic can be found in the following documents:
Dyn80param.txt (from v8.00 SDK)
CoreParams_900.txt (from v9.00 SDK)
CoreParams_1000.txt (from v10.00 SDK)
Just open the document and search for the function or procedure name and the parameter list will be provided. For example:
SYSTEM GLOBAL PROCEDURE: Messenger_Status
in string sMasterType;
in string sMasterID;
in string sAddressCode;
inout anonymous field IMVS;
optional inout anonymous field IMButton;
You can also use the Script Logging in runtime mode to get logs of 3rd party dictionary calls. You can use the Support Debugging Tool or manually add the Dex.ini settings as described in the following Knowledge Base (KB) article:
Using the script logging facility built into Dexterity along with the SDK it is possible to obtain the parameters for almost all functions and procedures in the system. If the dictionary comes from an ISV (Independent Software Vendor) and not Microsoft, you can contact their support team and they would normally be willing to provide the parameter list. If it is a Microsoft dictionary which is not included in the SDK documentation, you can ask on the newsgroups or open a support incident to ask for the parameter list.
I hope you you find this information useful.