Developing for Dynamics GP

Do we really want Windows Authentication for Microsoft Dynamics GP?

2009-12-09T01:00:00Z

Over the years, I have seen many requests for Windows Authentication support for Microsoft Dynamics GP, and I have to say I have mixed feelings about it. In theory, it sounds good, but in practice it may be a threat to your customer's financial information security.

Regardless of authentication method, users will still have to select a company to access which defeats the purpose of having a single sign-on.

If we have true Windows Authentication, then a workstation left unattended without being locked, could be used to access the financial system without the additional level of security of requiring a login. Also, if Windows Authentication is used, the password will not be encrypted (see article below).

The encryption of the passwords is what prevents access to the financial data using external tools to access the SQL Server. Having an encrypted password means that you must use the Microsoft Dynamics GP application to access the data and so are then subject to the application's security system. You cannot bypass the application level security as the password will not work from an external tool.

When a customer asks for Windows Authentication, I think we should not apologize and say that it is not supported. Instead we should sell the benefits of having an extra level of security provided by SQL Server Authentication with encrypted passwords. This extra level will protect the customer's valuable financial data.

Note: There are some third party ISV solutions which can synchronize the SQL user names and passwords with the Windows user names and passwords. While this simplifies the system by not having to remember more than once password, it is not true Windows Authentication.

For more information related to this topic, have a look at the following article:

Why does Microsoft Dynamics GP encrypt passwords?

Post a comment and let me know what you think?

David

What is the A4 Chunk?

2009-12-07T01:00:00Z

Recently on the newsgroups, I responded to two separate questions on the same day asking about handling A4 size paper with Microsoft Dynamics GP. So I thought a post about the A4 chunk would be helpful.

Background

Before the age of laser & inkjet printers (and after the daisy wheel and golf ball printers) the most common type of printer was the dot matrix printer. While dot matrix printers are capable of printing graphics or using graphic fonts, they were very slow when used this way. Historically, the dot matrix printer was used with a built in font which was non proportional (fixed width) and of a fixed style (eg. Courier, Helvetica, Times). If you had a good printer, you could print those fonts in bold and/or italic. The printers could printer either 10 (Pica), 12 (Elite) or 17 (Condensed) characters per inch (CPI) across the page and either 6 or 8 lines per inch (LPI) down the page. Unless you were lucky enough to have a wide carriage printer, your printer could print 8 inches wide (80 characters in 10 CPI mode ... the width of a text screen). The standard size of paper for this type of printer was 8.5 inches wide by 11 inches long. Sometimes it was a little wider and had tear-off sprocket holes... these were the holes on both sides of the paper that allowed it to be pulled through the printer.

So .... why the history lesson?

Well, because that standard size for computer paper became the standard size for paper in the USA, and is known as US Letter. OK, it might be possible that the paper size came first and the printers were made to match it.

On the other hand: A4 is an international standard (ISO 216) based on having an aspect ratio based on the square root of 2 (√2), or approximately 1:1.4142. The really cool thing about this is that if you fold or cut a piece of paper in half across its long side, the resulting sheet will have the exact same aspect ratio (just rotated 90 degrees). If you half an A4 sheet, you get A5. If you join two A4 sheets together you get A3. A4 size paper is the most common and is used in most countries outside of North America. Its dimensions in metric measurements are 210 × 297 mm.

For more information, you can see what Wikipedia says on its Paper size entry. The following diagram is from the Wikipedia page:

History

Prior to version 7.00 of Great Plains Dynamics and eEnterprise, paper sizes were not a major issue. This was because almost all reports were text based and were using the Best Text Fit option. This meant that when a report was printed the font used would be selected to ensure that the content to be printed would fit onto the printable area of the paper being used (based on paper size and the printer driver's margin settings for non-printable area). This automatically adjusting behaviour meant that most reports would work on either of the two main paper sizes without modifications.

With version 7.00 a number of reports which were previously text reports were converted to graphic reports and a number of new reports added as graphic reports. Graphic reports have a fixed size and do not have the option to automatically resize like a text report using the Best Text Fit option. So, graphic reports which have a layout based on US Letter sized paper do not fit well on A4 sized paper. Here is a summary of the paper sizes:

US Letter is 8.5" (216mm) wide by 11" (279mm) high.
A4 Paper is 8.27" (210mm) wide by 11.69" (297mm) high.

As you can see US Letter is wider and shorter than A4 paper. So in practical terms, if we look at the SOP Blank Invoice Form, when the US Letter version is printed on A4 paper, it will lose the right hand edge and the vertical lines will not join to the footer section to close the "boxes".

To help minimise the amount of report modifications that would be needed for an A4 based installation, a patching chunk was created to adjust graphic reports and some non landscape text reports so that the right hand edge does not have characters cut off. For graphic reports which have vertical lines, the lines were extended by 50 pixels to compensate for the longer paper size. This patching chunk is known as the A4 chunk (A4.CNK) and once installed it updates some 165 (approx.) reports in the core Dynamics.dic application dictionary.

The A4 chunk was original developed for Australian and New Zealand installations for v7.00 by the now defunct Asia Pacific Global Development Team which I was part of when I first joined Microsoft. The A4 chunk is now available for most country installations that would use A4 paper, United Kingdom, Australia, New Zealand, Singapore, South Africa, etc.

The following Knowledge Base (KB) article discusses the A4 chunk as it is a standard part of the Australian install:

Information about the localized code for the Australian version of Microsoft Great Plains (KB 910128)

Questions

So now that we know all about the different paper sizes and why the A4 chunk was created, what were the questions asked that prompted this article. Well, below are a list of frequently asked questions, including the ones from the newsgroups.

Q: When the A4 chunk is installed, I can't see it in Dynamics.set, why not?

A: The A4 chunk is a patching chunk that updates the Dynamics.dic file directly, you will not see it once it has been incorporated into the Dynamics.dic file. This is similar to how ??ERR.CNK files are used to update language and terminology.

Q: What files are updated by the A4 chunk?

A: The A4 chunk updates the Dynamics.dic file only.

Q: When I look at my report in Report Writer it has not been changed, why not?

A: The A4 chunk does not update the reports.dic at all. If a report already exists as a modified report it will not be updated by the A4 chunk. You would need to delete the modified report and then modify the original report again to get the updated version. Or you could manually update the report your self.

Q: What changes does the A4 chunk make to reports?

A: The changes vary depending on the report, the main changes are to shift the right hand columns toward the left a bit to allow for the narrower A4 page. For graphic reports with vertical lines, the length of the lines is increased by 50 pixels to allow for the increase in page length.

Q: How can I tell if the A4 chunk is installed on a system?

A: There is no version number or build number that can tell you that the A4 chunk is installed. Probably the easiest method is to open the SOP Blank Invoice Form and click on the first vertical line in the RH section. This line actually starts in the PH section but is easy to click on in the RH section. If the size is 0, 455 it is US Letter. If the size is 50 pixels longer, 0, 505 it is A4.

Q: Does the A4 chunk help with reports in 3rd party products?

A: No, the A4 chunk only updates the core Dynamics.dic application dictionary. Reports for products contained in other add on dictionaries will still need manual modifications.

Q: Can I have both US Letter and A4 reports on the same system at the same time?

A: Yes and no. You can have US Letter and A4 reports active in the same system, however, you will either need to install separate clients into separate application folders, or use separate reports.dic files. Most customers setup a US client folder and international client folder(s) as required.

Q: What reports are updated by the A4 chunk?

A: Attached to this post is a A4Readme.txt file which contains a list for v10.0.

I hope this article explains everything.

David

08-Dec-2009: Added Wikipedia links for the different types of printers.

Filtering eConnect Requester data

2009-12-03T17:00:00Z

I wanted to tell you about a recent case I had where the Partner was trying to restrict the Microsoft Dynamics GP data they had selected with the eConnect Requester Setup Tool.

They were first importing some of their Sales Orders from an external system into GP with eConnect. Then when they fulfilled and shipped the Order within GP, they used eConnect Outgoing Queue to make the updates available to the external system. Their use of GP also includes manually entered Sales Orders and they did not want the updates to the manually entered Orders to be queued.

So, the way the Requesters work is that boxes checked on each SQL table in the Requester Setup Tool cause a SQL trigger to be created when you click the Update button in the Tool. These triggers will fire upon an insert, update, or delete operation on the SQL table and cause rows to be created in the eConnect_Out table. The eConnect Outgoing Service queries the eConnect_Out table on a regular basis and pulls the data into your queue. You can look at the triggers in SQL Server Management Studio by right-clicking on the trigger and Script Trigger as Create to New Query Editor Window.

If you have some data values that distinguish the GP entered ones from the eConnect ones, you can use that to filter. For example, if you use different Document Numbers in the eConnect Sales Orders than you do in the manually entered ones you could put an if statement before the insert into eConnect_Out... statement to make sure that the rows are only created that you want created. The following example assumes we want Sales Orders with a Document Number starting with the letters "EC"

Example eConnect_Sales_TransactionSOP10200_UpdateTrigger change

if (@SOPTYPE = 2 and @SOPNUMBE like 'EC%')
begin
    insert into eConnect_Out(
    .
    .
    .
end

The dots in the example are the rest of the insert statement that is already in the trigger, and you put your end statement after that.

One last thing: if you are using eConnect to update the Sales Orders instead of updating with GP, you will need to set the RequesterTrx element to 1 (one) for this to work.

Enjoy!

Emily
Dynamics GP Developer Support

More on Windows 7, bitmap fonts and DPI settings

2009-12-02T01:00:00Z

This post is a follow up to the previous post on the topic which discussed how you can use the registry editor to adjust the font files used for bitmap fonts to restore them to the default 100% DPI size. If you have not read the previous post, please use the link below:

Windows 7, bitmap fonts and Microsoft Dynamics GP

As I hinted at in this previous post, any older applications that use bitmapped fonts such as MS Sans Serif, MS Serif and Courier are likely to have this same issue.

I have already explained the logic behind the change in behaviour for Windows 7 which can automatically set the DPI to 125% during the install. What has not been explained is why the bitmap fonts are not restored to 100% DPI when the DPI setting is changed back to 100% via the User Interface. This is the subject of this post.

How we see Windows is controlled by two primary settings: The resolution and the DPI setting.

In Windows Vista (and earlier) the resolution could be changed for each user on a workstation, but the DPI setting was system based. This means that a user did not really have full control of the settings for their profile and if another user changed the DPI setting, it would affect all users on that workstation. Changing the DPI setting would require a reboot for the change to take effect and it would adjust the bitmap fonts as part of that change.

So Windows 7 introduced a change to allow the DPI setting to be set on a per user basis (only requiring a logout and login to make the change). It is important to note that the user based DPI setting only affects the scalable fonts which can be adjusted without a reboot.

The bitmap font DPI settings are still system based and would still require a reboot to change and would also affect all users on the workstation. To avoid the now user based DPI setting from affecting other users in the system, the bitmaps fonts are no longer changed when adjusting DPI via the Display Control Panel applet.

The bitmap font size is now set only once during the installation and not altered thereafter. As we now understand, the initial DPI setting used during the install will control how the bitmap fonts are set.

I am researching if there is a way to make Windows 7 always default to 100% DPI during the installation, or a way to keep the bitmap fonts at 100% DPI size. However, if you DO want the 125% DPI setting, you will then have the same issue but the other way around.

Thanks to Peter Constable from the Windows 7 Development team for his input.

I hope this clarifies what is happening.

David

Checklist for creating a new Dexterity Window

2009-11-30T01:00:00Z

Today, we go back to basics. It is always good to make sure that we have the foundations handled properly. When I teach the Dexterity, I always go through the standard checklist below for creating (or modifying) Dexterity windows.

This checklist is valid for Dexterity when creating new windows or editing existing windows which will become alternate windows. It is also valid when using Modifier to modify existing windows.

Check the User Interface (UI)

There are User Interface Guidelines in Appendix F of the Dexterity Basics training manual (see links below). These guidelines should be followed to ensure that your windows or changes to windows cannot be told apart from the original windows. Some common issues I find are:

1) 3D line under the Window Control Area (Toolbar) to cover the black line is missing, or the line is present, but has not been made wide enough to fully reach the right hand edge of the window.

2) Buttons in the Window Control Area (Toolbar) are not separated by 2 pixels with a 3D vertical line (starting at vertical position 3 with length 16) between each button AND after the last button.

3) When two fields are next to each other the borders create a double thick line between them. To fix, click on the fields to the left and press Shift-Right Arrow to increase the size by 1 pixel.

4) When creating Scrolling windows, turn the borders off for the fields in the scrolling window and draw new borders with the line tool. Make sure that every drawn line is set to 2D Border. This will prevent the 1 white pixel of a vertical 3D line breaking up the horizontal lines.
Link Prompts

For the prompts to be "greyed out" when the field is disabled, hidden when the field is hidden or to show in a different style for a required field, the field must be linked to the prompt.
Link Lookups

For lookups to be be disabled when the field is disabled, or for the Ctrl-L keyboard shortcut to work, the field must be linked to the lookup button.
Tab Sequence

To make your windows keyboard friendly, the tab sequence should include all fields as well as the main action buttons. The first field in the sequence should be the first field on the window, which is usually the primary key field. The tab sequence should then work right, across the fields in a column then down the lines to the end of the section. Then if the window has more than one column, the tab sequence goes back to top of that column and works down. When the end of the section is reached it starts back at the top left of the next section and repeats zig zagging its way through the fields. Once the last field is reached then it should go through the toolbar buttons and then finally any buttons at the side or bottom of the window.

Note: Remember to press Tab in between each field when setting the tab sequence, otherwise the tab sequence will be reversed.
Position Window

You should position the window away from the top left corner. If this window will be used with other windows, you can position it so that it will be visible or at least not completely hidden by the other windows.
Resizing

If the field includes fields that can be resized, such as lists, scrolling windows, treeviews or listviews, you might want to change the window to use per field resizing and then define the behaviour wanted for ALL fields, prompts and lines. Use the Ctrl-5 preview mode from window layout to test the resizing.
Compile

Always compile all the code when you think you have finished. Logical errors cannot always be avoided, but leaving syntax errors in code is completely avoidable.
Test

Everything you develop should be tested and tested and then tested again. By the way... did I mention that you should test your code.

Here are the links for the Dexterity training materials (which include the UI guidelines):

Dexterity Basics for Microsoft Dynamics GP 9.0

Dexterity Integration for Microsoft Dynamics GP 9.0

Note: The latest materials are for v9.0, but the content is applicable to v10.0 and later.

If you are new to Dexterity, this article will help you learn what you need:

Dex - How to get started with Dexterity

Hope you find this best practice checklist useful.

David

Running dag.exe on 9.0 Dynamics forms dictionary fails with runtime error at 86% complete

2009-11-27T01:00:00Z

A few months ago, a partner was attempting to create an Application.Dynamics.ModifiedForms.dll using the Dictionary Application Generator (dag.exe) against his 9.0 SP4 Dynamics forms dictionary.

This failed for him. Trying to determine if it was a "forms dictionary issue" or not, he renamed his Application.Dynamics.dll as a test and attempted to generate a new one using Dag.exe. This also failed in the same manner but at a different spot.

The partner logged a support incident that I took and after making sure that dag.exe ran successfully on my 9.0 SP2 system, I updated to 9.0 SP4 as well. After doing so, I found I had the exact same issue.

So that was nice - at least I could replicate the issue.

What we found was that generating the modified forms assembly using the command line:

Dag.exe 0 /F

The Dag.exe would fail with a Microsoft Visual C++ runtime error at 86% complete.

If we renamed the Application.Dynamics.dll and attempted to generate it again with the command line:

Dag.exe 0 /M

Then the Dag.exe would fail with a Microsoft Visual C++ runtime error at 17% complete.

After spending a good time debugging this in Visual Studio 2005, I was able to determine what was happening.

Sometime after 9.0 SP2, two procedures were introduced into the Dynamics.dic. These procedures used parameters that included two new fields. Unfortunately however, the fields themselves were not included in the update cnk file.

While not causing any issues for the GP client - as I believe the new procedures would only be used for Latin American customers - the Dag.exe was finding the procedures and attempting to locate the new fields in the dictionary. As they didn't exist, the runtime crashes on the first one it couldn't find.

While very unusual for support to do, the workaround was for me to make a cnk file that contains the missing fields that would merge into the Dynamics.dic. After giving the cnk file to the partner and merging it into his Dynamics.dic, his dag.exe would run to completion successfully.

This issue is scheduled to be fixed in the next release - probably a tax release coming up. In the meantime, if you run into this issue log a support case and mention that you need the MBSGP_53972.zip file to resolve this issue. Also make sure you give your exact dictionary version 9.0.352 or 9.0.371 as the cnk file will alter your Dynamics.dic and they need to be the same version. As this is a bug, you won't be charged for the case.

Hope this helps,
Patrick
Developer Support

Windows 7, bitmap fonts and Microsoft Dynamics GP

2009-11-25T01:00:00Z

I have a story to tell..... and it even has a happy ending.

During the last week of August 2009, I was over in Sydney at the Microsoft Office in North Ryde for meetings and to catch up with my Australian based colleagues on the Asia Pacific support team for Microsoft Dynamics GP. While there I downloaded the DVD images for Windows 7; both the internal Microsoft IT Windows 7 Enterprise build and the Windows 7 Ultimate RTM build.

When I returned home in early September, I rebuilt my laptop with Windows 7 using the internal Windows 7 Enterprise install. I wrote about this at the time: Windows 7 and Microsoft Dynamics GP.

What I did not mention in the previous article is that I noticed that the font size in Microsoft Dynamics GP (and some other older applications) was incorrect. Eventually (after two weeks of not being able to fix the font issue), I rebuilt my machine with the Windows 7 Ultimate install and the problem was gone. At the time I believed that it was somehow related to the internal build only and so would not affect people outside of Microsoft. Thus there was no reason to write about it publically on the blog.

Here is an example of what I mean, using the main window of my favourite add on product, the Support Debugging Tool for Microsoft Dynamics GP. I am not biased really.... :-)

The window should look like this:

The issue affects the Dexterity "System" font used by Microsoft Dynamics GP. It has also shown up in some older applications which use the same font. This font is actually the bitmap MS Sans Serif font at the Windows level but is called "System" in the Dexterity development environment. Most newer applications use fonts as specified by the Window's themes and so do not have any issues. Note there is a font at the Windows level called "System", but that is not related to this issue.

In the screenshots above, you will notice that the prompts and fields on the window, which use the MS San Serif font, are displayed a couple of points bigger than they should be, this causes the writing to get cut off and the window to look ugly. Also note that the fonts in the window title bar, the menu bar and the heading are the same size in both screen shots and that they are smoothed using ClearType... this is because they are using TrueType scalable fonts and not a bitmapped font.

Moving forward in time about 3 months.....

I came across a newsgroup post in which Andrew Cooper mentioned that the fonts on his system where bigger than they should be. This sounded very familiar and meant that the issue was not limited to inside Microsoft and so would need to be investigated again.

Below is a summary of what is happening and the details of the fix required. Thanks to Peter Constable of the Windows 7 Development team for helping explain what was happening.

Research showed that many users with high resolution monitors (particularly LCD flat screens) were running the monitors at lower resolutions than the native resolution of the screen. This was usually because at the native resolution, the fonts were becoming too small to read, so the users would decrease the resolution.

Windows includes a facility to increase font and window sizes while keeping the screen at the native resolution. This is a much better method of increasing the font size as it can produce much smoother images by using many more, smaller pixels. The really significant issue is, unlike CRT monitors, flat-panel LCD monitors have a fixed pixel size, or "resolution", and that when users change to a lower resolution (in order to increase text size) the system has to re-sample the lower-resolution display image into its fixed resolution causing a significant degradation in display quality: not just text looks worse, everything looks worse.

A change was made for Windows 7, to set the screen resolution to the monitor's native resolution and if the screen is over a certain resolution to default the font size 120 DPI (dots per inch). This is approximately 125% of normal 96 DPI (100%). When the system defaults to 125% DPI it also adjusts the MS Sans Serif font to be bigger. If the user then decides to set the DPI back to 100%, then TrueType fonts, which are scalable, adjust as expected. But the bitmap MS Sans Serif font does not: it remains at the larger size, hence our issue. This problem does not occur if Windows 7 keeps DPI at 100% when it is first installed.

In my case, the internal Windows 7 Enterprise build had an appropriate video driver for my machine and was able to go to the native resolution (1920 x 1200) and default to 125% DPI. As my machine is older, when I installed the Windows 7 Ultimate build, it did not have the video driver and so defaulted to a lower resolution at 100% DPI. Once I installed the video driver from Windows Update, I was able to get to the native resolution and remain at 100% DPI. Because the initial setting was 100% DPI, the MS Sans Serif font was the correct size.

I realised that the issue is not an internal problem, but can occur on any Windows 7 system that has a high resolution monitor for which drivers can be found during the initial install and so default with 125% DPI. If the user returns to 100% DPI, the MS Sans Serif bitmap font will remain larger.

The solution took a while to find, but is really simple. We just need to make some registry changes and reboot.

Note: The registry changes do not take effect until the system has been restarted. You MUST reboot after making the registry changes.

The Registry setting HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts\MS Sans Serif 8,10,12,14,18,24 is set to SSERIFF.FON on a system which started at 125% DPI. The setting is set to SSERIFE.FON on a system which started at 100% DPI. Notice that one character of the file name changes from F to E.

The actual font files used might be different on Windows systems for other languages or code pages. See the table below for the file names:

125% DPI font file 100% DPI font file

SSERIFF.FON SSERIFE.FON

SSERIFFE.FON SSERIFEE.FON

SSERIFFG.FON SSERIFEG.FON

SSERIFFR.FON SSERIFER.FON

SSERIFFT.FON SSERIFET.FON

SSEF1255.FON SSEE1255.FON

SSEF1256.FON SSEE1256.FON

SSEF1257.FON SSEE1257.FON

SSEF874.FON SSEE874.FON

125% DPI font file	100% DPI font file
SSERIFF.FON	SSERIFE.FON
SSERIFFE.FON	SSERIFEE.FON
SSERIFFG.FON	SSERIFEG.FON
SSERIFFR.FON	SSERIFER.FON
SSERIFFT.FON	SSERIFET.FON
SSEF1255.FON	SSEE1255.FON
SSEF1256.FON	SSEE1256.FON
SSEF1257.FON	SSEE1257.FON
SSEF874.FON	SSEE874.FON

While we are fixing the MS Sans Serif font, we can also fix the MS Serif and Courier fonts. These are the Registry settings MS Serif 8,10,12,14,18,24 and Courier 10,12,15 values in the same registry key. See the table below for the file names:

125% DPI font file 100% DPI font file 125% DPI font file 100% DPI font file

SERIFF.FON SERIFE.FON COURF.FON COURE.FON

SERIFFE.FON SERIFEE.FON COURFE.FON COUREE.FON

SERIFFG.FON SERIFEG.FON COURFG.FON COUREG.FON

SERIFFR.FON SERIFER.FON COURFR.FON COURER.FON

SERIFFT.FON SERIFET.FON COURFT.FON COURET.FON

SERF1255.FON SERE1255.FON COUF1255.FON COUE1255.FON

SERF1256.FON SERE1256.FON COUF1256.FON COUE1256.FON

SERF1257.FON SERE1257.FON COUF1257.FON COUE1257.FON

125% DPI font file	100% DPI font file	125% DPI font file	100% DPI font file
SERIFF.FON	SERIFE.FON	COURF.FON	COURE.FON
SERIFFE.FON	SERIFEE.FON	COURFE.FON	COUREE.FON
SERIFFG.FON	SERIFEG.FON	COURFG.FON	COUREG.FON
SERIFFR.FON	SERIFER.FON	COURFR.FON	COURER.FON
SERIFFT.FON	SERIFET.FON	COURFT.FON	COURET.FON
SERF1255.FON	SERE1255.FON	COUF1255.FON	COUE1255.FON
SERF1256.FON	SERE1256.FON	COUF1256.FON	COUE1256.FON
SERF1257.FON	SERE1257.FON	COUF1257.FON	COUE1257.FON

To fix the system you need to change the settings to new file names (changing the appropriate letter from F to E) and reboot.

Note: The registry changes do not take effect until the system has been restarted. You MUST reboot after making the registry changes.

Below are the contents of Font Fix.reg file to make the changes for an English system:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts]
"MS Sans Serif 8,10,12,14,18,24"="SSERIFE.FON"
"MS Serif 8,10,12,14,18,24"="SERIFE.FON"
"Courier 10,12,15"="COURE.FON"

An archive of the Font Fix.reg file for an English system is also provided as an attachment at the bottom of this post.

While I have focussed on the MS Sans Serif bitmap font (as this is the one used by Microsoft Dynamics GP) as well as the MS Serif and Courier fonts, this issue is likely to affect other bitmap fonts. Other bitmap fonts can be found in the \Windows\Fonts folder as *.FON files and in the same registry location.

I hope you find this information helpful.

David

02-Dec-2009: Please see follow up post: More on Windows 7, bitmap fonts and DPI settings.

09-Dec-2009: Further highlighting of the need to reboot after making registry changes.

Accessing a Table Buffer when it is not passed as a parameter

2009-11-23T01:00:00Z

This post is a follow up to the previous posts on the Three Trigger Technique. If you have not read the posts explaining this technique, please use the links below:

Using the Dexterity Three Trigger Technique Part 1

Using the Dexterity Three Trigger Technique Part 2

The idea of the three trigger technique is to use a trigger on an unrelated function or procedure call to get the timing you require for your code. The 1^st and 2^nd triggers are used to ensure that the 3^rd trigger is only used when it is called from your desired parent script.

This post discusses a method that can be used in conjunction with the three trigger technique. In the example code supplied in the part 2 post, we were able to capture a reference to the table buffer we needed because the table was passed as a parameter to the parent script. But, what happens when the table buffer you need is not available as a parameter?

Before we get to the actual code I should clarify that while I can write code to use a table which is defined in Dynamics.dic, or use pass through code with the execute() function to use a table in a third party dictionary. However, the table buffer used will be a new private instance created for the duration of the code. To use the same table buffer as the original code requires a reference to the table buffer to be captured and stored. Then this reference can be used or passed as a parameter.

We will discuss three methods that can be used to capture that all important table reference:

Method 1: When the table is a parameter to another function or procedure called prior to your triggering point.

You can add a fourth trigger to your scripts running before the original code of the function or procedure that passes the table as a parameter. This trigger's purpose is just to capture the table reference so it can be used in our code later.

Example Trigger handler script

inout table XYZ_Table;

{ If not inside the three trigger code, do not continue }
if not 'MBS Trigger Active' of globals then
	abort script;
end if;

{ Capture Table Reference }
assign 'MBS Table Reference' of globals as reference to table XYZ_Table;

Method 2: When the table is attached to a form.

The following scripts demonstrate how to capture the table buffer reference after the first get table or change table command is issued against that table. By using a global integer variable to store the trigger tag returned when registering, we are able to enable and disable the table trigger as needed. The trigger is disabled once the reference is captured so that it does not affect performance.

Global Procedure: Startup

{Turn off the warning for literal strings}
pragma(disable warning LiteralStringUsed);

{ Check not in Test mode and 3rd Party XYZ installed }
if not empty(Launch_GetFileName()) then
	if Launch_GetProdPosition(MBS_PROD_XYZ) >= 1 then
	
		if Trigger_RegisterDatabaseByName(MBS_PROD_XYZ, "XYZ_Table", "XYZ_Form", TRIGGER_ON_DB_READ+TRIGGER_ON_DB_READ_LOCK, script MBS_XYZ_Table_READ, 'MBS Table Trigger Tag' of globals) <> SY_NOERR then
			warning "Trigger After table XYZ_Table READ Registration Failed.";
		else
			{ Disable Trigger for now, triggers below will re-enable }
			Trigger_DisableSingle('MBS Table Trigger Tag' of globals);

			if Trigger_RegisterFocusByName(MBS_PROD_XYZ, "form XYZ_Form", TRIGGER_FOCUS_PRE, TRIGGER_BEFORE_ORIGINAL, script MBS_XYZ_FORM_PRE) <> SY_NOERR then
				warning "Trigger Before form XYZ_Form PRE Registration Failed.";
			end if;
		
			if Trigger_RegisterFocusByName(MBS_PROD_XYZ, "form XYZ_Form", TRIGGER_FOCUS_POST, TRIGGER_AFTER_ORIGINAL, script MBS_XYZ_FORM_POST) <> SY_NOERR then
				warning "Trigger After form XYZ_Form POST Registration Failed.";
			end if;
		end if;

	end if;
end if;

{Turn the literal string warning back on}
pragma(enable warning LiteralStringUsed);

Global Procedure: MBS_XYZ_FORM_PRE

{ Enable Table Trigger }
Trigger_EnableSingle('MBS Table Trigger Tag' of globals);

Global Procedure: MBS_XYZ_FORM_POST

{ Disable Table Trigger, if not already disabled }
Trigger_DisableSingle('MBS Table Trigger Tag' of globals);

{ Clear Table Reference }
clear 'MBS Table Reference' of globals;

Global Procedure: MBS_XYZ_Table_READ

inout anonymous table XYZ_Table;
in integer IN_Operation;

{ Capture Table Reference }
assign 'MBS Table Reference' of globals as reference to table XYZ_Table;

{ Disable Table Trigger now that we have table reference captured }
Trigger_DisableSingle('MBS Table Trigger Tag' of globals);

Method 3: When the table is a local instance created in a function or procedure.

This method is similar to the method above, but uses triggers on the function or procedure and has to use an unrestricted table trigger (i.e. not linked to a form).

Global Procedure: Startup

{Turn off the warning for literal strings}
pragma(disable warning LiteralStringUsed);

{ Check not in Test mode and Copier Series installed }
if not empty(Launch_GetFileName()) then
	if Launch_GetProdPosition(MBS_PROD_XYZ) >= 1 then
	
		if Trigger_RegisterDatabaseByName(MBS_PROD_XYZ, "XYZ_Table", "", TRIGGER_ON_DB_READ+TRIGGER_ON_DB_READ_LOCK, script MBS_XYZ_Table_READ, 'MBS Table Trigger Tag' of globals) <> SY_NOERR then
			warning "Trigger After table XYZ_Table READ Registration Failed.";
		else
			{ Disable Trigger for now, triggers below will re-enable }
			Trigger_DisableSingle('MBS Table Trigger Tag' of globals);
			
			if Trigger_RegisterProcedureByName(MBS_PROD_XYZ, "XYZ_Script", TRIGGER_BEFORE_ORIGINAL, script MBS_XYZ_Script_PRE) <> SY_NOERR then
				warning "Trigger Before XYZ_Script Registration Failed.";
			end if;
		
			if Trigger_RegisterProcedureByName(MBS_PROD_XYZ, "XYZ_Script", TRIGGER_AFTER_ORIGINAL, script MBS_XYZ_Script_POST) <> SY_NOERR then
				warning "Trigger After XYZ_Script Registration Failed.";
			end if;
		end if;

	end if;
end if;

{Turn the literal string warning back on}
pragma(enable warning LiteralStringUsed);

Global Procedure: MBS_XYZ_Script_PRE

{ Enable Table Trigger }
Trigger_EnableSingle('MBS Table Trigger Tag' of globals);

Global Procedure: MBS_XYZ_Script_POST

{ Disable Table Trigger, if not already disabled }
Trigger_DisableSingle('MBS Table Trigger Tag' of globals);

{ Clear Table Reference }
clear 'MBS Table Reference' of globals;

Global Procedure: MBS_XYZ_Table_READ

inout anonymous table XYZ_Table;
in integer IN_Operation;

{ Capture Table Reference }
assign 'MBS Table Reference' of globals as reference to table XYZ_Table;

{ Disable Table Trigger now that we have table reference captured }
Trigger_DisableSingle('MBS Table Trigger Tag' of globals);

Hope you find this technique a useful addition to your arsenal.

David

Microsoft Dynamics GP Testing 101 Session

2009-11-20T01:00:00Z

After spending a great week with attendees at the Microsoft Dynamics GP Technical Conference 2009 in Fargo, I decided to try my hand at contributing to the Developing for Dynamics GP blog. I am a Test Engineer on the GP team focusing on Dexterity and as such I had the pleasure to present a Dynamics GP Testing 101 session at the Conference with my teammate Grant Swenson. So today I wanted to highlight the key takeaways from the session as well as provide links to a couple of great reference materials that are available today.

First off, when thinking about how to approach creating a test environment for your solution, take some time to identify the areas you need to test in and the starting point that can provide a good foundation for your tests. Do you need a large set of starting data or will a smaller subset do? On the environmental side, are there integrating applications, printers or things like specific date, time or currency formatting you need to utilize in your solution? Once you have identified these things, determine how you will get your system back to this starting point after testing has been done. That may mean taking database backups to restore later or using BCP to pull the data out, etc. Whatever that method is, the first critical part in starting the testing process is figuring out how to replicate and return to your starting point. If there was one piece of information for attendees at the presentation to take away it is that consistency is key. Replicating the same environment you first created tests in to rerun them and verify the results can give you a big boost towards success and make things like troubleshooting errors much, much easier to do.

Secondly, there are all sorts of tips for creating Dexterity macros or doing things like SRS testing. The main thing to remember here is that you want to start off taking small steps. Don’t try to cover every scenario and have all the data you possibly can be recorded or sent out to an output file. This gets to be quite a chore to verify and most times will leave you frustrated with the whole process. By approaching a small piece of your solution, figuring out the data you will need for that piece and then recording a macro to test that part, can oftentimes be the best way to start. It can also help you to provide some very useful feedback to the rest of the development team much sooner on the quality of a feature or product.

For those who are looking into bringing automated tests into their development environments, there are two released resources available today that can help paint the full picture of the considerations to take and how to start when recording macros for your Dexterity solutions. The first is in the Dexterity documentation. The document to look at is called the Programmer’s Guide Volume 2 and more specifically in Chapter 34: Testing Your Application. Now, if you aren’t a developer don’t be scared away by the word "Programmer’s" in the title. This is a great all around resource that describes the Dexterity macro system that can be used for business logic automation or for testing so be sure to check it out. The second resource that really pulls all the pieces together for you when starting down the automation path is the whitepaper called, "Recording Test Cases with the Macro System" (also attached). This is found on the Microsoft site and walks through the importance of creating a starting point, how to get started with macros and helpful .ini settings as well as what to do after you have created your first macros.

Check these two resources out and see if you can take the first or next step into bringing some automation into your development organization. There are numerous benefits including increasing the overall chances of having successful deployments at your site or your customer sites as well as lowering the overall cost of a project by finding defects in the solution before it goes the door. At the conference we also previewed a test automation framework sample. Stay tuned for more information to come on that once we find a good home for it to be shared with you!

Have a great day and happy testing!

Alice

Microsoft Dynamics GP Technical Conference 2009 Wrap Up

2009-11-18T01:00:00Z

So the conference is over and in my opinion it was a great success. I would like to thank all the team members involved at all levels for putting on a great event and making everyone feel so welcome. The friendly atmosphere is one of the reasons I really enjoy going to Fargo (in spite of the extremely long travel times).

Below are the links for all the Conference posts by myself and some of the other bloggers in the community:

From this blog by David Musgrave

From the Dynamics GP Blogster by Mariano Gomez

From Inside Dynamics GP by Andy Westby

Live from Fargo…

From the Edge by Gerice Anderson

Microsoft Dynamics GP Developers Stampede to Fargo

Hope you enjoy the coverage of the conference.

Please post your comments and feedback on the event and let us know your thoughts.

David

Coming home from the Microsoft Dynamics GP Technical Conference 2009

2009-11-16T01:00:00Z

This is the final diary style post on my trip to the Microsoft Dynamics GP Technical Conference 2009. Hopefully you have enjoyed reading about the events of the trip. As far as I am concerned it was a great success. The conference, my sessions, the meetings and the socialising with partners and Microsoft staff all added up to make a fantastic but tiring trip.

I started my journey at 11:30 when I checked out and left the Ramada hotel. My first flight left Fargo at 13:00 arrived an hour later in Minneapolis/St Paul. I wanted to organise my seats of the two Qantas flights and so was looking for a WiFi connection I could use. Sadly, there was no free connections available. I decided to browse through a gadget shop (OK, I admit it... I like cool gadgets). While there a gentleman asked about Australian power plug adapters and I ended up chatting with him. It turned out that Brian was heading over to Sydney for a work meeting in the Hunter Valley (a great wine region). When he found out that I wanted to get an internet connection, he took me to the Delta/Northwest lounge as a guest. Once he had got me into the lounge and told me how to get onto their WiFi, he left for his flight. Thank-you Brian for your help, which allowed me to get the blog updated.

My flight from Minneapolis left at 17:00 and was uneventful, arriving 4 hours later in Los Angeles at 19:00. I spent a couple of hours in the One World lounge (working this post). The long haul (15 hours) flight left Los Angeles at 22:30 on Saturday night and arrived in Sydney at 08:30 Monday morning. As we crossed the international date line, Sunday will just disappear during the flight.

This is the bit that I hate. After being away from home for a period of time, I am finally back in Australia, but I am still a five hour flight away from Perth. While in Sydney Airport, I met a couple of other Microsoft guys who were heading from Redmond (Seattle) to Hobart in Tasmania. I helped get them into the Qantas lounge so they could get internet access and refreshments before their connecting flight. After just under an hour waiting, I left Sydney at 10:00 and arrived in Perth 5.5 hours later at 12:30. A half hour taxi ride from the airport and I am finally home after 36 hours on the move.

I think I will sleep for the rest of the day!!! After I surprise my youngest, Rohan, by picking him up from school.

David

17-Nov-2009: Rohan was happy to see me. Also, I did not get to sleep early in the end and am still tired.

18-Nov-2009: See the Microsoft Dynamics GP Technical Conference 2009 Wrap Up for more posts.

Meetings after the Microsoft Dynamics GP Technical Conference 2009

2009-11-14T01:00:00Z

If you are going to spend a day and a half getting somewhere and a day and a half going home, you want to spend more than two or three days at your destination.

My trip to Fargo included the days for the conference, but also one day before and two days afterward in the Microsoft office. The additional days were spent filled up with meetings relating to my role as Escalation Engineer on the Asia Pacific (APAC) support team for Microsoft Dynamics GP. Yes, I do actually have a job to do beyond responding on forums and newsgroups and writing blog articles.

I won't bore you with details, but I will say that all the meetings went really well. A couple of the meetings were related to my pet projects of the Support Debugging Tool and Menus for Visual Studio Tools. At these two meetings I outlined my plans for the releases of these tools and got approval for those plans. You will see these releases as soon as I can complete the development, testing and documentation work needed. I will post the details when they are released.

One of the saddest parts of the day was saying goodbye to Mariano when the time came for him to head out to the airport and start his journey to Atlanta, Georgia. It has been a wonderful experience working with him over the last 18 months online and now in person. I look forward to a long and fruitful relationship with him. Hopefully, you will see us presenting again soon.

Saying goodbye to Mariano

After the meetings on Thursday, I went to Granite City bar and grill for dinner with some of Scott Stephenson's team (Developer Support and Escalation Engineers) and brought out the Arnott's Tim Tams chocolate biscuits again. A number of the team tried the Tim Tam Slam (see previous post for details) and enjoyed the very yummy but potentially messy experience.

Scott Stephenson being a great sport and doing the Tim Tam Slam

On Friday, I demonstrated the Support Debugging Tool twice to some of the internal support teams with the aim of driving adoption and use of the tool by the Microsoft Dynamics GP support teams.

For dinner on Friday, I caught up with ex-Microsoftie, Sheila Ochoa and her family. She invited her friend Debbie Larson, who works at Microsoft and originally comes from the UK. We spent some time re-living the past and comparing notes and listening to English music from the 1980's. Believe it or not, she comes from the same part of London that I lived in before I came to Australia and knew the school that I went to as a child. Sometimes it is amazing how small the world can be.

David

18-Nov-2009: See the Microsoft Dynamics GP Technical Conference 2009 Wrap Up for more posts.

Duplicate key error on a range copy statement

2009-11-13T09:00:00Z

An ISV ran across an interesting problem a few days ago in his Dexterity/Dynamics 9.0 solution.

The goal of a particular procedure was to copy records from one table into a nearly identical duplicate temporary table. The duplicate table contained all of the original table fields plus a few new ones. The temp table was created by using the Duplicate feature in Dexterity so the keys of the new table were identical to the original table.

The ISV code was using was essentially:

Dexterity Code range copy table MyTable to table MyTableTemp; check error; {check error for debugging purposes} warning str(err()); {for debugging purposes}

You would expect that this would work fine however what what we found that no records were copied and the error message given on the check error statement was:

A range copy statement on table MyTable has created a duplicate key.

The err() function returned 17 - DUPLICATE which was consistent with the check error statement.

Puzzling. I admit that my first instinct was that there WAS a duplicate being generated. I've seen that a number of times and have done it myself once or twice. Take a table and range copy it into another table that has different (unique) keys and depending on your data this will work OK sometimes and sometimes not.

But why don't the non-duplicates get inserted? The reason you don't end up with any data is because SQL rolls back the records on the insertion failure and so you don't get any records in the target table.

So why isn't this the solution? Because the ISV duplicated the original table meaning the original keys were duplicated as well (and he assured me he didn't add any new ones) and so if the original table allowed the data the duplicate should also.

But yet we apparently were getting a duplicate created.

After determining that there wasn't a code issue and the table definitions were all OK, the next step was to turn on the SQL Server Profiler to see what SQL was complaining about.

To test this, I duplicated the RM_Customer_MSTR table and added the Vendor ID field to the end of the table. I also set the physical name of the table to "temp" to make sure my test was the same as the ISV's.

The Dexterity statement used and the SQL Statement generated by the range copy operation is shown below. I removed mosf of the columns since you don't need to see them all to see the issue.

Dexterity Code and SQL Trace results

range copy table RM_Customer_MSTR to table RM_Customer_MSTR_Temp;
INSERT INTO ##2033653 (CUSTNMBR, CUSTNAME, CUSTCLAS, <removed>, INCLUDEINDP) 
  SELECT CUSTNMBR, CUSTNAME, CUSTCLAS, <removed>, INCLUDEINDP FROM TWO.dbo.RM00101 
 

The one thing I noticed is that the VENDORID is not included in the insert/select statement generated. So in that case, on a SQL insert where a column is ignored then SQL fills it with the bound default (if available) or null if not. Well, this is a temp table so there is NOT a bound default and so the column should be getting a null which isn't allowed by the constraints that Dexterity puts on table columns during table generation.

So where is the duplicate? There isn't one.

Turning on the Error Messages in our SQL Profiler during our range copy statement, SQL tells us the actual issue which is what I was thinking it to be after verifying the table keys.

Cannot insert the value NULL into column 'VENDORID', table 'tempdb.dbo.##2033653; column does not allow nulls. INSERT fails.

Well that explains it. The new columns are ignored and get the column default which is null. Nulls are not allowed and so it fails with no inserts.

In this case, the Dexterity error message given is completely incorrect and misleading - one of the very few times I can think of that has been the case.

There are several solutions that I can think of depending on circumstances.

If this wasn't a temp table and instead a permanent table, then you can make sure that your columns are bound to the appropriate defaults. So in this case, the binding constant for the VENDORID column is GPS_CHAR. Since the column has a legal default this would just work.
Loop through the original table in a while statement and copy the records one by one to the target table. This will work because Dexterity will supply the default for the new columns. Of course this is slow since these are single inserts in a loop. Very inefficient but it would work.
Use pass through SQL and write the correct code yourself. In this case, I added the VENDORID column to the list of column fields in the target table and set the default to be an empty string (which is not NULL). This was the solution we employed for the ISV.

INSERT INTO ##2033653 (CUSTNMBR, CUSTNAME, CUSTCLAS, <removed>, INCLUDEINDP, VENDORID)
SELECT CUSTNMBR, CUSTNAME, CUSTCLAS, <removed>, INCLUDEINDP,'' FROM TWO.dbo.RM00101
Upgrade to 10.0. The range copy statement was enhanced for 10.0 to handle the new columns in the target table. In this case, Dexterity would generate the SQL statement from #3 above and the range copy operation would work successfully.

So the next time you are using Dexterity to perform a range copy operation, think about your keys on the target table to make sure that you couldn't get a legitimate duplicate. And if you are 9.0 and have new columns in the target table, consider using methods #2 or #3 above instead of a straight range copy statement.

Best regards,

Patrick
Developer Support

Microsoft Dynamics GP Technical Conference 2009 - Day 2

2009-11-12T01:00:00Z

After staying up until the early hours of the morning, it was hard to get up again. I met Leslie, Mariano and Jaydel Gluckie from Horizons International for breakfast and then we headed over to the Microsoft Fargo campus. The Fargo campus is now the largest Microsoft campus outside of the Redmond campus.

We went back to our meeting room, finished making the changes we had worked out last night and printed out our notes. We were finally all ready for the second session. I think that next time I present at a conference with a co-presenter, I will organise to get to the location earlier and have another couple of days before hand to fine tune everything .... in person.

The presentation of "Troubleshooting Your Developed Solution" went well. It was not quite as crowded as the Customizing session, but the attendees liked what they saw. In the session we went through some theory of software development and testing before covering the tools available to you to troubleshoot issues in the different development environments. We sped through the presentation (on purpose) so we could spend most of the session running through a demonstration of the Support Debugging Tool for Microsoft Dynamics GP.

After the session, Mariano, Leslie and I reviewed the demonstration and discussed how we can tweak a couple of sections. After lunch, we presented the Troubleshooting session again and the repeated session was even better than the original. I must say that Mariano had none of the concerns of the day before, he is a seasoned professional now.

I want to really thank Leslie, who gave Mariano and I her time and fantastic knowledge to make this session awesome. She attended the session both times it was run and helped us keep on time so that we finished within the 75 minutes we had for each session. If you were there and enjoyed the session, please know that it was a combined effort from Mariano and myself as well as Leslie.

Next time, I will request for the Support Debugging Tool to have a session of its own as it definitely has enough in it to fill a session by itself. We can then give the session a more accurate title, so attendees know what they will be seeing. This will also allow us to spend more time on the troubleshooting methods with the development tools and we can do some demonstrations of how to solve various issues. Maybe next conference there will be three sessions.... Customizing, Troubleshooting and the Support Debugging Tool.

As we finished our final concurrent session, the rooms were prepared for the closing session. I managed to get hold of my friend Jeff Trosen long enough to get a photo. Here he is with Babs Coler who organised the conference.... Thanks Babs for a great event.

Left to Right: Jeff Trosen, Me (again) and Babs Coler

The closing session included a Questions and Answers (Q&A) section which started off by Mark Rockwell (Rockton Software) and of course Bill Marshall (MC²). The Q&A session was MC'd by Dave Coulombe and had a panel representing all the different areas of Microsoft Dynamics GP organisation. We also had an fantastic presentation by John Hancock on the new Microsoft Power Pivot tool for extremely fast Business Intelligence analysis.

Left to Right: Jeff Trosen, Chad Sogge, Gary Tronson, Scott Stephenson and Errol Schoenfish

After the closing session we had one last Study Hall session... read as ... time to socialize with the partner attendees and the Microsoft staff. Not surprisingly, I ended up with the Dexterity development and support teams.

Left to Right: Dave Dusek, Patrick Roth, Erik Nissen, Alice Newsam, Rob Anderson & Brian Roney

After conference finished, Mariano and I had been invited to a small gathering with the Product Management team at Errol and Cheri Schoenfish's house. I brought some Arnott's Tim Tams chocolate biscuits with me from Australia and challenged everyone to try the Tim Tam Slam. This is where you bite off both ends and use the Tim Tam as a straw to suck up a hot drink. You need to put the Tim Tam in your mouth as soon as the hot drink touches your tongue as the biscuit will disintegrate very fast.

Errol Schoenfish doing the Tim Tam Slam (thanks for letting me post this)

The conference was over and everything was a great success. But my trip was not over yet.

David

17-Nov-2009: Materials for the Troubleshooting session are attached to the bottom of this post.

18-Nov-2009: See the Microsoft Dynamics GP Technical Conference 2009 Wrap Up for more posts.

Microsoft Dynamics GP Technical Conference 2009 - Day 1

2009-11-11T01:00:00Z

Wow, what a ride!!

I will apologize that this update has taken until now to post, but writing blog posts requires time and that is the one thing that has been at a premium over the last few days.

On Tuesday, I arrive on the first full day at the conference to hear someone call out my name..... someone who still has an Australian accent. I turn around to find none other than Geoff Harding. Former work colleague from Sequel Technology who now lives in the USA and works for Wennsoft. Geoff wrote the Equipment Series while at Sequel Technology, he even let me write a few sections of code. It was great to see Geoff again as I only see him now at Microsoft Dynamics GP conferences. I had brought some Vegemite with me from home to give as a gift and so who better to receive it than a fellow Aussie.

Geoff Harding (tall one) and David Musgrave (short one)

The Conference started with opening session with Dave Coulombe, Errol Schoenfish and Jeff Trosen welcoming us to Fargo. During the session, Martin Olsen and Chris Dew from eOne Business Solutions demonstrated some of the new "Forms" functionality that was added to the Extender product for v10.0 Service Pack 4 and later. They created a great example on-the-fly of a system to track professors, classes and students. For some reason, they enjoyed picking on me by using my name in their demo data and setting me as a junior level trainer using the lowest hourly rate. Errol also showed a great video which attempts to explain why 11 is better than 10.

After the opening session came the first concurrent session time slot. There were two sessions offered for each time slot and one of these first sessions was Mariano and my "Customizing the Microsoft Dynamics GP Client with Visual Studio Tools, Dexterity and Modifier with VBA" session. As we are getting ready for the session, setting up the machines and getting the microphones put on, Mariano is looking more and more uncomfortable. I knew that this was his first time presenting to a large public audience, and understood that he would be nervous. While he got me worried, after a quick break to get some fresh air he was ready to go. I had faith in him and it was well rewarded. The session was standing room only and was a great success. We went through eight demos showing how to use four different tools in two ways to achieve similar customisations. He was a lot more relaxed after the session.

Mariano (looking more relaxed) and David

After our session, we attended the Rob Anderson's "What's New in Dexterity for Microsoft Dynamics GP 11?" session which showed us some of the cool things coming in the next set of the tools. Here are a couple of them: Context menus in Dexterity and Table buffer parameters for Visual Studio Tools. We also attended Rob Wagner's "Emailing Documents and Word Templates" session, which showed us how the new Word forms functionality works when printing documents such as SOP Invoices.

After the three concurrent sessions there was an ISV Expo and Reception. Mariano, Leslie Vail and I stayed for a little bit and then went to a meeting room to prepare for our Troubleshooting session the next day. In particular we were working on demonstration of the Support Debugging Tool for Microsoft Dynamics GP. We made good progress but were not finished when we ran out of time and went back to the conference to participate in the Study Hall sessions.

While there I was able to catch up Dave Coulombe, who I have known since I first started with GP in 1994.

Dave Coulombe and David Musgrave

I was also able to meet and greet with a number of partners, Microsoft staff and long time friends.

Left to Right: Emily Roen, Leslie Vail, David Musgrave, Constance Gilleland, Denni Conner

At the end of the Study Hall time (9pm), we (Mariano, Leslie and I) caught the bus back to the Ramada hotel and found a table in the Basies restaurant that had a power socket. We sat down with some drinks and snacks to eat and continued to work on the demonstration for tomorrow's session. By the time we finished, it was 1:30am and we were all exhausted.

I must thank Mariano and Leslie for spending the time working through the ideas I had to streamline them, improve them and make them work smoothly.

We were finally ready for the session, just need to update the document with the handwritten notes and print the cheat sheets out.

By the time I got to sleep, I had four hours before I had to get up again.

David

17-Nov-2009: Materials for the Customizing session are attached to the bottom of this post.

18-Nov-2009: See the Microsoft Dynamics GP Technical Conference 2009 Wrap Up for more posts.