#GPPT Using Microsoft Dynamics GP with High DPI on High Resolution Monitors

David Meego - Click for blog homepageIn the last eight years, there have been an increasing number of display issues when using Microsoft Dynamics GP on high resolution monitors. There are a number of different factors coming into play which cause Dynamics GP to display incorrectly.

This article explains the issues, their causes and their solutions and finally explains how GP Power Tools makes the solutions extremely simple to implement.

The first issue was discovered by me back in 2009 when Windows 7 was released.

Bitmap Fonts

Most of Microsoft Dynamics GP’s user interface is generated from Dexterity (the development tool behind Dynamics GP) and its windows. By default, the font used on all the text on a window is the Dexterity System font. This font is displayed in windows using the MS Sans Serif bitmap font.

As a bitmap font, it is not scalable like a TrueType font would be. You will also notice it has no aliasing which means it does not work with the ClearType technology built in to Windows. Below is an example window created in Dexterity showing the various fonts as well as a 400% magnified close up with shows the aliasing in action.



Bitmap fonts lack the ability to dynamically resize as they are defined by a series of dots in a bitmap instead of as a series of vectors, curves and lines. In fact, Windows only has two sizes defined for bitmap fonts 100% and 120%. These two sizes for each bitmap font are stored in separate .FON files in the C:\Windows\Fonts folder.

Dynamics GP’s windows are built expecting the 100% version of the bitmap fonts to be used, and so all the spacing and sizing of the window and its controls are designed to fit with that sized font.

With Windows 7, when it first installs and identifies the system as having a high DPI monitor (which included 1920×1080 FullHD), it decided to be “helpful” and set the display DPI to 125% or 150%. Along with the DPI change, Windows would set the default bitmap font size to 120%.

Even though you can return the display setting back to 100%, the bitmap font size set in the registry is never changed by Windows after that initial install. The result was that the font used on most windows in Dynamics GP was too big as shown in these old screenshots:

Incorrect: 120% bitmap font size

Correct: 100% bitmap font size

You will notice that the window titlebar & menubar and window heading font sizes were correct in both as they are not bitmap fonts. You need to reset the fonts back to 100% for Dynamics GP to display correctly.

Bitmap Scaling

Windows 7 added the ability for individual users to have different DPI values on a single workstation, but that DPI setting was for all monitors connected. With Windows 8.1, the ability to have different DPI settings for each monitor was added and in Windows 10 this functionality has been extended and improved. This would all be wonderful in a world where all applications were multi-monitor DPI aware.

The next issue is that Microsoft Dynamics GP is not DPI Scaling aware. In fact there are many applications which are not DPI scaling aware, many applications which can only handle a single system DPI settings (was per pre Windows 8.1) and a few applications that are multi-monitor DPI aware.

When running at a DPI setting higher than 100%, Windows will instruct applications to adjust their size accordingly, the problem is that not all parts of all applications know how to do that. In Dynamics GP, there are some newer components to the user interface that can resize such as the application level toolbars. As the homepage is rendered using HTML, it can resize just like an internet browser can. However, the Dexterity based windows cannot resize and will be displayed at 100% and look tiny and unreadable on a high resolution screen.

My Surface Book runs at (3000×2000) resolution on a 13.5″ display and anything displayed at 100% size is just too small to work with. I use 150% DPI which gives a virtual resolution of (2000×1333) which is fairly close to my 27″ external monitor which runs at (2560×1440) at 100% DPI. As I drag a window (eg. Windows Explorer) from one monitor to the other, it resizes and ends up being about the same size relative to the desktop work area and to my eyes. This is how it is meant to work.

Below is an example of Microsoft Dynamics GP with its “mixed mode” DPI scaling with some bits huge and other bits tiny.


I have seen some different results with different versions of Microsoft Dynamics GP. For example: For me, Microsoft Dynamics GP 2016 looks like it will work correctly during login, but once logged in, the screen reverts to 100% is unusable.

Anyhow, there is a solution and it is called Bitmap Scaling. It was brought to my notice by fellow MVP, Steve Endow who applied to Dynamics GP the technique he discovered from a post by SQL consultant, Gianluca Sartori.

It works on Windows 10 and possibly on Windows 8.1 (I don’t have a machine to test). The solution works with two steps.

  1. A Registry Setting which tells windows to use a manifest file to control scaling, if it is present. (Restart required)
  2. A manifest file for each executable application that needs to declare it is not DPI Aware.

Once Windows identifies an application as not being DPI Aware, it will implement bitmap scaling to allow it to scale on the monitor with the correct DPI setting applied. It does this by running the application at its native 100% scaling off-screen and then renders the windows on the monitor using an interpolated zoom.

This method can introduce some blurriness to the resulting window depending on the DPI setting. For example: at 200% DPI, every pixel can become 4 pixels (stretched by 2 in both directions) and the resulting image should be fairly crisp. I use 150%, which means that each pixel becomes 2.25 pixels (stretched by 1.5 in both directions) and so will be blurred slightly.


The end result is still much more usable than before, even with some blurriness.

Scrollbar Width

When Windows uses DPI Scaling to adjust the sizes of the windows, the Scrollbar width on the window can get wider. On some transaction windows which have the scrolling windows with a column of numbers on the right hand edge, this can cause the last digit to get covered up.


It is possible to force the width of the scrollbar to remain at the fixed value of 17 pixels, which is the size the windows were created with.

Window Positions

Another issue that has been causing issues especially in multi-monitor configurations is that windows in Dynamics GP which remember their positions can open outside of the visible area of the Desktop and hence appear not to open at all (especially the Note windows).

I did publish a keyboard sequence which can be used to make the window visible again but can offer a much better solution now. Never allow the window to even open off screen again.


The solutions to all of these issues is GP Power Tools. While there are manual solutions to these issues, GP Power Tools simplifies everything by providing the user interface to make all the changes needed. You will need the latest Build 21 (Last Modified: 05-Nov-2016) code installed for these functions to be available.

Just launch Microsoft Dynamics GP using Run as Administrator, then go to GP Power Tools >> Cards >> Dex.ini Settings . This will allow the registry settings and file changes in the program folders to be applied. These settings need to be applied for each workstation.

Below are the Windows Bitmap Font and Windows Bitmap Scaling settings as well as the Scrollbar width override setting:


To ensure a window never opens outside the visible area of the desktop, go to GP Power Tools >> Setup >> Administrator Settings >> Usability Settings, and ensure the highlighted setting is selected. This setting is system wide and will take effect on next login for on all workstations where GP Power Tools is installed (which should be all of them!).


Note: Prior builds of GP Power Tools do not have the Bitmap Scaling settings and have a calculation issue with automatic window re-positioning on high DPI monitors which could cause windows to move incorrectly.

If you like the window’s colors in the screenshots above, that is added using the Company based Color schemes feature of GP Power Tools. Watch the video here: GP Power Tools Videos.

More Information

For more information on the manual solutions to these issues, see the articles below:

Hope this is helpful


This article was originally posted on http://www.winthropdc.com/blog.

7 thoughts on “#GPPT Using Microsoft Dynamics GP with High DPI on High Resolution Monitors

  1. I believe that GP2010 lacks the “high DPI aware” flag and uses bitmap scaling by default. GP2013 appears to have introduced the flag and started the problem of everything being too small on high DPI monitors. I did find there was a problem with GP2010’s bitmap scaling and Mekorma MICR. The check printing would go through GDI and the check would get scaled as well. This led to unacceptable clipping and we had to tell our users that print checks they must use 100% scaling on their computers. I don’t know if newer versions of MICR avoid this problem.

    I hope we are getting closer to Microsoft dumping dexterity and rewriting the UI using a modern language. Even before high DPI was a problem, GP windows regularly had problems regularly diverging from established Windows design guidelines. And the lack of a splitter control has frustrated SmartList users for years.

    Thanks for the helpful tips to help make GP more usable in a high DPI world. We just need Microsoft to require that their GP developers and testers use high DPI monitors. I’m sure all this would get straightened out very quickly after that directive was implemented. 🙂


    • Hi Marc

      Dexterity will not be going anywhere, it will always be the development tool behind Dynamics GP.

      What needs to be done is changing the system font to Helvetica (Arial) and then making Dexterity DPI Aware.



      • Making dexterity DPI-aware seems like it would be quite a big undertaking. Given that Microsoft has refused to devote the resources to develop a dexterity splitter control makes me think it is unlikely they would devote the necessary resource to add high DPI support.

        DPI problems are just the latest flaw surfacing about dexterity. To me, it looks like the long-term goal might be to discontinue the desktop client in place of the web client. That would allow Microsoft to get rid a lot of the legacy baggage.


      • Hi Marc

        I developed a Dexterity Splitter control which is used in a number of the windows in GP Power Tools. Microsoft decided not to implement the same methodology (even though I gave them a demo), because it would not work on the web client. In the end, they decided on a collapsible left pane, which would be web client compatible.

        There is way too much investment in Dexterity from both Microsoft and ISVs to try and move away from the tool. Much of the functionality such as Web Client and Service Based Architecture as well as older functionality such as Modifier, Report Writer and Visual Basic for Applications all work because it is supported by Dexterity.

        While there is a Dynamics GP product, it will ALWAYS be based on Dexterity. There is no goal to discontinue the desktop client, but they do want to make as much of the product work well with the web client as possible.



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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s