Those of you who attended Microsoft Convergence 2011 Atlanta will know about the promised Build 15 of the Support Debugging Tool for Microsoft Dynamics GP. Well it is finally here with over 80 changes to the code. It includes lots of new functionality as well as many fixes and improvements. This build can be installed over the top of any existing installed build without needing to remove the old build first.

Below is a summary of the changes made for releases 10.00.0015 and 11.00.0015, I have divided them into logical sections:

Fixes

Fixed Dictionary Control to not enable triggers for all products unless Dictionary Control is actually in use.

Fixed Call Stacks in Use Error when using Reject Script option on the Automatic Debugger Mode Setup window.

I have been beta testing the Support Debugging Tool (SDT) for Dynamics GP for a couple of weeks. My first impressions orbited around admiration for the author, none other than David Musgrave, followed by the natural curiosity on the powerful features provided by the tool itself.

The product is compatible with releases 8.0, 9.0, and 10.0. SDT was first introduced during the Microsoft Dynamics GP Technical Airlift , in May of 2008 with great reception from the attending partner community. Unlike the Script Debugger Tool (activated by including ScriptDebugger = TRUE in the Dex.ini file) Support Debugging Tool is geared towards the consultant and end-user to assist in troubleshooting application issues without the complexities involved in understanding the application development process.

Modes of Operation

The Support Debugging Tool offers two modes of operation: Standard Mode and Advanced Mode.

The Standard Mode is a read-only mode which helps with application logging and providing resource and security information.

The Advanced Mode adds triggering and scripting capabilities, data export and import and dictionary control. The Advanced Mode is activated by controlling settings in the Dex.ini file -- all from the interface and without leaving Dynamics GP! This mode of operation has been conceived with the systems administrator and partner support staff in mind since it delivers powerful options including the ability to visualize…

It has been a while since we had a new build of the Support Debugging Tool for Microsoft Dynamics GP. So we have decided to release Build 14. This is primarily a maintenance release with bug fixes, minor enhancements and a couple of new features. This build can be installed over the top of any existing installed build without needing to remove the old build first.

Please note that this is the final release for version 9.00.

Below is a summary of the changes made for releases 9.00.0014, 10.00.0014 and 11.00.0014, I have divided them into logical sections:

Fixes

Changes to Reject Script functionality in Advanced Debugging Mode to restore fields to their previous values.

Changes to Reject Script and Reject Record functionality so it can be controlled by using the OUT_Condition variable.

One part of the demo was how to solve security privileges errors using the tool. It is a perfect example of how the tool can make administration for a Microsoft Dynamics GP system so much simpler and this is why many partners are now installing the tool on all workstations of all their customer sites.

In our scenario, the user is receiving a security error, but the window they were trying to open still opens, however, the window that opened does not include some fields added as a customisation. We are assuming that the Support Debugging Tool is already deployed to all workstations on the system.

The case I was working on was an error dialog generated on the Receivables Cash Receipts window. However, if the window was opened directly from the navigation pane or menus, there was no error. If the window was opened using the Transaction Button from the Receivables Batch Entry window, the error dialog was generated.

As per standard procedure, we always ask if there are any customizations involved, and were told by the partner that there were no customizations to the Receivables Cash Receipts window.

So, after some research into the source code to confirm the possible reasons for the dialog to show, I was unable to find anything that could…

FICTION: Once you have the archive zip file for your version of Microsoft Dynamics GP, just copy the files into your Microsoft Dynamics GP application folder (need at least the Debugger.cnk and Debugger.pdf) and launch Dynamics GP using Run as Administrator. Copying the Debugger.pdf allows the F1 key to open the User Guide from inside Dynamics GP.

Note: You need to give all users access to the MBS_DEBUGGER_USER Security Role to use the standard mode features. The upcoming build 15 or later builds will offer to apply this security change for you.

The SDT is hard to setup

FICTION: No setup is required, however to get the most out of the tool, it is best to use a central location of the Debugger.xml setup file. The Debugger.pdf User Guide manual has a section on Recommended Configuration which gives step by step instructions with screenshots on how to configure the SDT to use a central location. Just use a folder in the same path you use for OLE attachments for Notes.

The SDT can only capture logs

FICTION: The SDT can capture logs either manually or automatically, but that is only a small part of the overall functionality and features of the tool. As the SDT does not need to change Dex.ini settings to capture logs it can capture logs without having to exit the application and come back AND it only captures for the current instance of the application. If you change Dex.ini settings on a Terminal Server it can affect all instances from multiple users.

The SDT only needs to be on one machine

FACT & FICTION: To capture logs or perform most features you can install the SDT on only one machine, BUT to get the most out of the tool including the centralised administration functions you should have the SDT installed on all workstations AND use a central location for the Debugger.xml setup file.

The SDT should be installed on all machines

FACT: To get the most out of the SDT, you should have it installed on all workstations in your system. Features such as differentiating companies using colour coding and changing the window Title will only work if the tool is installed. Also, if you have to exit to install the tool when you have a problem, you might not be able to reproduce the issue once logged back in. Having to tool installed and waiting means it is there when you need it.

The SDT should use a shared location for the setup file

FACT: To get the most out of the SDT, you should configure it to use a central…

I am currently working on a support case where the customer is making use of the six user defined categories for items. That in itself is nothing remarkable or worth blogging about. However, they are using Long Description field on the Item Category Setup window and wished to include the data from this field onto reports. That's the difficult bit.

The problem with getting these fields to display on a report is that there is no way to create a relationship to the IV_User_Category_SETP (IV40600) table from the array of Item Category Values fields stored agains the IV_Item_MSTR (IV00101) table. The reasons is that the Item Categories are stored using a primary key of an Item Category Number (1-6) and an Item Category Value. To create the relationship, we need to provide both the Number and the Value, we can get the Value from array field, but there is no table field containing the Number and the relationship functionality of Report Writer does not allow a constant value to be provided.

I checked the Dynamics.dic source code for a Report Writer function to be able to access this data and none were available. In fact, the Long Description field for Item Categories does not appear to be used anywhere else in the application.

To get this data to be available to a report, it is possible to use the Support Debugging Tool's support for the 6 user defined report writer functions described in the following Knowledge Base (KB) article:

The 6 functions; rw_ReportStart(), rw_ReportEnd(), rw_TableHeaderCurrency(), rw_TableHeaderString(), rw_TableLineCurrency(), and rw_TableLineString() are placeholder functions in the core Dynamcis.dic dictionary. They contain no code (just parameters), but are available for Dexterity developers to trigger against and return data to a report.

A great example of these functions in use is to include Extender fields on a report. The following KB article explains to to achieve this:

More times than I care to count I have been called in to fix records left behind because the Include Totals and Deposits option was not marked when transferring a sales document from an existing order to an invoice. The problem is, it is so easy to forget to mark that box if you are doing this for hundreds of transactions fractured in multiple batches, especially at the end of the week when invoices need to be submitted to customers, prior to the FedEx truck arriving at 4:00 PM.

Sales Transfer Documents window

While this "fix" has been provided as a Modifier with VBA project before, I thought, why not really prop this up a bit with a Support Debugging Tool non-logging trigger and take advantage of the Automatic Debugger Mode functionality? Well, I have done just that!

The first thing we need to do is setup the trigger itself. In this case, we want to select a Focus Event trigger that will fire exactly on a field change condition. The field in question is the '(L) Order To Invoice CB' checkbox field. You can use the lookup button next to the Form Name field on the Resource tab to open the Support Debugging Tool's Resource Explorer…

This post is to announce that an updated Build 15 labelled as Last Modified: 22-Jul-2011 has been released for Microsoft Dynamics GP 10.0 and Microsoft Dynamics GP 2010. This build has 3 bug fixes in it, one major fix and a couple of cosmetic ones (shown below):

Fixed initial position for Support Debugging Tool Main window not opening in bottom right corner.

Here is a quick explanation of the ScreenShot issue. There were two issues/changes from the previous Build 14 code of ScreenShot:

The first issue was that it was possible for the emailing functionality of ScreenShot to attempt to create the email and add the attachments before the creation of the screenshot bitmaps had been completed. This "timing" issue would mean that not all of the screenshot bitmap files would be attached to the email. ScreenShot uses the built in Macro system to generate the screenshot bitmaps and so to resolve this timing issue the macro file ran by ScreenShot needed a button to press once it had finish…

Today, I will touch on the topic of Automatic Debugger Mode and non-logging triggers again. However, this time I will show how you can use non-logging triggers in combination with logging triggers to capture vital application logs upon the occurrence of some Microsoft Dynamics GP application event without user intervention.

This may sound a little esoteric, but the concept is simple. For this example we will use the Vendor Maintenance window, a very familiar window to most of you who interact with Microsoft Dynamics GP on a daily basis.

Vendor Maintenance

For this example, we will register two non-logging triggers on the Vendor Maintenance form: the first non-logging trigger will start up a logging trigger that initiate application events logging - DEXSQL.LOG and Dexterity Script Log for this example - when the Hold checkbox is activated. The second non-logging trigger will stop the logging trigger upon closing the Vendor Maintenance form.

As you may know, I have been working with Support Debugging Tool since the pre-release of build 9 and have been a contributor to the development and beta testing of the product since that time. Today marks the release of Build 11, the third installment of the product, in a marathonic 130-hour development effort by my friend David Musgrave. Read what David has to say and the myriad of enhancements introduced in this build in his release notes article.

The focus of this post is the new Company Colour Coding feature.

I am very excited about this feature for many reasons, but I will highlight two scenarios where I find it highly valuable:

1) With the introduction of Microsoft Dynamics GP 10.0 came the release of the Single Document Interface (SDI). SDI is a method of organizing graphical user interface applications into individual windows that the operating system's window manager handles separately. A window does not have a "background" or "parent" window containing its menu or toolbar; instead, each window contains its own menu or toolbar. Release 10 marked the departure from the Multiple Document Interface (MDI) that was known to hundreds of thousands of users around the world for more than 20 years.

However SDI introduced another challenge to the user community and the question did not wait: "I used to work with multiple instances of GP at the same time and had no problems differentiating my sessions. With this new interface how can I tell my companies apart?" While the usual response to this question was the company name on each window, this did not stop users…