In the past, I have had some cases where users have reported that the Microsoft Dynamics GP application default printer as set by Named Printers keeps getting changed back to the Windows Default printer. The cause of this issue was never really identified…. until now. A current case with a similar issue finally helped explain what was happening.
It turns out that Microsoft Dynamics GP 9.0 and before (for a number of versions) had a check in the runtime engine for when the Windows Default Printer was changed, so it would update the application default printer for Microsoft Dynamics GP. The idea was to avoid having to also manually change the application default printer when the Windows Default Printer changed. In a Terminal Server/Citrix environment this allowed for the default printers to be updated even after the Dynamics GP application was launched.
When Microsoft Dynamics GP was changed from the MDI (single window) to the SDI (multiple windows) interface for version 10.0, this code was broken as the handling for it was in the v9.0 style application shell. For version 10.0 SP5 and GP 2010 this was fixed to restore the previous behaviour of updating the application default printer.
The way that the change of the Windows Default Printer was “captured” was with a generic windows event telling use that settings had changed. This event can fire when the printer is changed, but also when the screen resolution was changed and possibly other windows settings as well. Whenever this event fired, Dynamics GP would refresh the application default printer from the Windows Default printer.
Well, this generic event was also firing when unlocking a locked workstation. So locking the workstation manually or via a screensaver would change the printer when you unlocked the workstation. This behaviour has been confirmed on Windows XP and Windows 7 RTM, but doesn’t happen in Windows 7 SP1.
The problem report for this issue is currently scheduled to be looked at for inclusion in the next release of Dynamics GP.
- Problem Report 62939: Dexterity re-defaults windows printer even though the printer hasn’t changed
So this explains what is happening and that a fix should be coming in a future release. So what can we do about this now?
Well, in the meantime, to provide an alternate solution, you can use the Support Debugging Tool to create non-logging triggers on the Windows Activate event of commonly used windows to call the code to reset to the Named Printers default printer. The Windows Activate event is fired whenever a window gains focus.
To set up the trigger you just need to give it a name and description, set it to Start Trigger Automatically on Login and Don not active Logging Mode. Then set the Type as a Focus Event, the Event as Window Activate and the Attach mode as After Original. You can then select the form and window (usually the main window) of any commonly used forms (especially ones from which the users print).
Add the script below running in the context of Microsoft Dynamics GP. The script does not need alteration based on the form or window being used.
Trigger Script Example
The Support Debugging Tool Configuration Settings file for this Non-Logging Trigger SOP_Entry example code is attached to the bottom of this post.
You can use the Duplicate button to copy the Trigger for other forms, just use Ctrl-A, Ctrl-C to grab of copy of the script before changing the form and window (as this resets the script). Change the form and window and then use Ctrl-A, Ctrl-V to replace the default script.
Hope this information is useful.