Named Printers application default printer selections not "sticking"

David Meego - Click for blog homepageIn 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).

Note: This screen shot is from build 15 of the SDT and looks different to previous builds.

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

out boolean OUT_Condition;

OUT_Condition = false;

{---- Set up the Named Printer default printer ----}
if upper(Defaults_Read(ST_SETDEFAULT)) = TRUE_STRING then
 call ST_Printer_Restore_Default;
end if;

// Copyright © Microsoft Corporation.  All Rights Reserved.
// This code released under the terms of the
// Microsoft Public License (MS-PL,

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.


Debugger Settings Printer

Comments (6)

  1. David Musgrave says:

    Posting from Mark Polino at…/named-printers-application-default.html

  2. David Musgrave says:

    Posting from Mariano Gomez, The Dynamics GP Blogster…/default-printer-not-sticking-when.html

  3. Bill says:


    We are running GP 2010 in a terminal server environment, and notice that if a user launches the GP application prior to all of the printers being mapped, they will end up with the wrong default printer.  Your article suggests that GP should detect the new default printer once they are finally loaded, but it isn't working.   Did I interpret your article correctly that this should be the case?



  4. David Musgrave says:

    Hi Bill

    The updating of the Dynamics application printer when the Windows default printer is changed occurs when the printer is changed by the user. I don't think it will happen if the Windows default printer is changed by the system after Dynamics GP has been launched.

    Also Named Printers will not be able to change to a printer ID if that printer ID is not yet available.  It is best to wait until all printers are available before launching GP.


  5. Crystal Roach says:

    David – I have a client with xp pro workstations.  One workstations works perfectly, but the other does not.  Is it possible doing the windows updates will correct this issue.  I have no idea when the users last updated their operation systems.

  6. David Musgrave says:

    Hi Crystal

    Make sure the second workstation has its own Machine ID.

    Recreate the Printer ID and assign them to tasks.

    if you still have trouble look at…/troubleshooting-named-printers-issues.aspx


Skip to main content