Using the Support Debugging Tool to create temporary fixes

David Meego - Click for blog homepageThis is a reposting of an article I originally wrote on my Developing for Dynamics GP blog.

The Support Debugging Tool for Microsoft Dynamics GP has the facility to create non-logging triggers.  This are Automatic Debugger Mode triggers that do not automatically start and stop the Dexterity and SQL logging.

Non-logging triggers have two purposes, they can be used when looking for the cause of issues to execute additional code to help with the debugging work, for example: reading data and storing it in the log for later analysis; or popping up a dialog to confirm a particular piece of code has been executed.

However, they can also be used to execute additional code that can be used to temporary fix an issue or quickly prototype code for a permanent fix. Once the temporary fix has been tested, it can be used while a more permanent solution is developed.

From Build 11 or later non-logging triggers have the option to execute reject script (on focus events before the original) or reject record (on scrolling window fill events) commands to stop further processing of the original code.


One issue I have come across a number of time recently is related to setting up Named Printers on a Terminal Server.  The following post highlights how changing the Printer Class drop down list on the Assign Named Printers Window will remove all the existing settings for the old class in preparation to enter new settings for the new class.  This can cause all the settings for other users or users & companies to be lost without warning. [Edit: This issue is fixed in Microsoft Dynamics GP 2010.]

I have requested that a warning dialog be added to prevent this accidental data loss, but in the meantime have developed a temporary fix using the Support Debugging Tool and a non-logging trigger.  Below is a screenshot of the settings used as well as the script.  Before you manually add this into your system, you can download the settings file from the attachment linked to the bottom of this article.

Below is the script used. Note that OUT_Condition is set to true when the dialog is displayed and the user decides not to continue. As we have marked the Reject Script option, this tells the Support Debugging Tool to prevent the original code from being executed.

Script for Named Printers Fix

in string IN_OldValue;
in string IN_NewValue;
out boolean OUT_Condition;

local integer iSeries;
local boolean l_found;

iSeries = itemdata('Printer Series' of window ST_Printer_Assign of form ST_Printer_Assign, 'Printer Series' of window ST_Printer_Assign of form ST_Printer_Assign);

OUT_Condition = false;

if value(IN_OldValue) > 1 and value(IN_OldValue) <= 4 then { User, Company, User & Company }
  range clear table ST_Printer_Settings_MSTR;
  set 'Machine ID' of table ST_Printer_Settings_MSTR to 'Machine ID' of window ST_Printer_Assign of form ST_Printer_Assign;
  set 'Printer Series' of table ST_Printer_Settings_MSTR to iSeries;
  set 'Printer Task' of table ST_Printer_Settings_MSTR to 'Printer Task' of window ST_Printer_Assign_Scroll of form ST_Printer_Assign;

  set 'Location Code' of table ST_Printer_Settings_MSTR to "";
  set 'Printer Mode' of table ST_Printer_Settings_MSTR to integer(value(IN_OldValue));

  fill 'User ID' of table ST_Printer_Settings_MSTR;
  fill 'Company ID' of table ST_Printer_Settings_MSTR;
  range end table ST_Printer_Settings_MSTR by number 1;
  clear 'User ID' of table ST_Printer_Settings_MSTR;
  set 'Company ID' of table ST_Printer_Settings_MSTR to -1;
  range start table ST_Printer_Settings_MSTR by number 1;

  get first table ST_Printer_Settings_MSTR by number 1;
  if err() = OKAY then
    l_found = true;
  else
    l_found = false;
  end if;

  range clear table ST_Printer_Settings_MSTR;

  if l_found then
    { Settings in previous mode exist, warn before wiping them }
    if ask("Changing the Printer Class will remove the existing settings for this Printer Task for the current Machine ID, continue?", getmsg(YES), getmsg(NO), "") = ASKBUTTON2 then
      'Printer Assign Mode' of window ST_Printer_Assign_Scroll of form ST_Printer_Assign = integer(value(IN_OldValue));
      focus 'Printer Assign Mode' of window ST_Printer_Assign_Scroll of form ST_Printer_Assign;
      OUT_Condition = true;
    end if;
  end if;
end if;

Note: The Reject Script functionality requires Build 11 or later of the Support Debugging Tool to be used.

This code will pop a dialog to prevent accidental data loss and allow the user to prevent the change to the Printer Class drop down list.

The settings file suitable for v8.0, v9.0 and v10.0 is attached to the bottom of this article. Use Configuration Export/Import to install the file.

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

12-Mar-2011: Added note that the issue is fixed in Microsoft Dynamics GP 2010.

Debugger_Settings_NamedPrinters.dbg.zip

This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on http://www.winthropdc.com/blog.

6 thoughts on “Using the Support Debugging Tool to create temporary fixes

Please post feedback or comments

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.