Using the Support Debugging Tool with Function and Procedure parameters

Article
05/10/2009

David Meego The Support Debugging Tool for Microsoft Dynamics GP has the ability to create triggers against Functions and Procedures (both global level and form level). While this functionality allows us to identify when a particular function or procedure has been executed, it is unable to obtain the parameters used when the call is made.

The problem is that the Support Debugging Tool (SDT) creates triggers on-the-fly, which means that the trigger handling code is generic and does not have parameters in it. The only method of obtaining the parameters is have a procedure or function created which has the matching parameter list to the original code.

So how can I capture the parameters so I can use them with the Support Debugging Tool?

You will need to create a custom chunk file with Dexterity. The purpose of this custom code is purely to trigger on the function or procedure and store the parameters passed in. Then the script from the Automatic Debugger Mode trigger in the Support Debugging Tool can read the previously stored parameters and use them as desired.

The best method to explain this is with an example. Let's assume I need to track calls to Named Printers when reports are printed. The ST_Set_To_Default_Printer() function is called before a report is printed to obtain the printer settings to be used. We are going to trigger on this function and store the parameters so that the Support Debugging Tool can read them when it triggers. The required custom code is below:

Trigger Handler: MBS_ST_Set_To_Default_Printer_PRE function code

 { Trigger Handler for ST_Set_To_Default_Printer function }
function returns 'Printer Settings' PrinterSettings;

in integer IN_Printer_Series;
in string IN_Printer_Task;
optional in 'Location Code'   IN_Location_Code;

{ Store the Parameters }
call with name "MBS_Param_Set" in dictionary 5261, "IN_Printer_Series", str(IN_Printer_Series);
call with name "MBS_Param_Set" in dictionary 5261, "IN_Printer_Task", IN_Printer_Task;
call with name "MBS_Param_Set" in dictionary 5261, "IN_Location_Code", IN_Location_Code;

Trigger Registration: Startup Procedure Code

 pragma(disable warning LiteralStringUsed);

if Trigger_RegisterFunction(function ST_Set_To_Default_Printer, TRIGGER_BEFORE_ORIGINAL, function MBS_ST_Set_To_Default_Printer_PRE) <> SY_NOERR then
  warning "ST_Set_To_Default_Printer function pre trigger registration failed.";
end if;

pragma(enable warning LiteralStringUsed);

We can now create and install the chunk with these two scripts into the live system.

Now in the Support Debugging Tool's Automatic Debugger Mode setup I can create the following trigger, which will read the previously stored parameters and can then use them. In this example I am using them to write a line in to the Support Debugging Tool's log with the parameters listed.

Named Printers Example

Trigger Script Example

 out boolean OUT_Condition;
local string MBS_Parameter;
local integer l_Printer_Series;
local string l_Printer_Task;
local string l_Location_Code;

OUT_Condition = false;

call with name "MBS_Param_Get" in dictionary 5261, "IN_Printer_Series", MBS_Parameter;
l_Printer_Series = integer(value(MBS_Parameter));
call with name "MBS_Param_Get" in dictionary 5261, "IN_Printer_Task", l_Printer_Task;
call with name "MBS_Param_Get" in dictionary 5261, "IN_Location_Code", l_Location_Code;

call with name "MBS_Auto_Log" in dictionary 5261, "ST_Set_To_Default_Printer Parameters: "
                                                  + str(l_Printer_Series) + " "
                                                  + l_Printer_Task + " - "
                                                  + l_Location_Code;

if true then { Insert Condition Here }
  OUT_Condition = true;
end if;

{ Clean up }
call with name "MBS_Param_Del" in dictionary 5261, "IN_Printer_Series";
call with name "MBS_Param_Del" in dictionary 5261, "IN_Printer_Task";
call with name "MBS_Param_Del" in dictionary 5261, "IN_Location_Code";

Note: For this to work correctly it is important that the custom trigger runs before the Support Debugging Tool trigger. Triggers run in the order they are registered and as the custom trigger is registered during Startup and the Support Debugging Tool's trigger is registered later at login, the custom trigger will always be executed first.

This method allows a developer to still use all the functionality of the Support Debugging Tool while getting access to the parameters of a function or procedure.

For more information on the Support Debugging Tool, please look at the articles below:

For other related articles and posts have a look at the Support Debugging Tool Tag page.

David

Using the Support Debugging Tool with Function and Procedure parameters

Additional resources