If you have a relatively new Windows laptop with a high resolution display or if you have 4K monitors on a Windows desktop, you are likely familiar with the numerous software display issues related to these "high DPI" displays.
If you use a 4K monitor at full resolution, the fonts and text in Windows is microscopic. To make text readable and buttons large enough to click, Windows uses "scaling", whereby it increases the size of text and graphics to make them readable and large enough to actually use. (I'm sure there's a huge technical discussion about the details, but I don't care about any of that, I just want to get work done.)
So when you run Windows 10 with a high DPI display, it will typically recommend running at 200% scaling. I prefer to use 175% to get more real estate on my displays.
This Scaling technique generally works well, and with many applications, you may not even realize that scaling is occurring...
Until you launch an application that isn't "high DPI aware" or high DPI compatible. Then you'll see a complete mess. I use SugarSync, which does not handle scaling very well. Notice the text on the left is very small compared to the folder names on the right.
It's annoying, but tolerable.
I thought that Dynamics GP 2015 displayed fine on my Surface Pro 4 when I first installed it, but I rarely use GP on my SP4, and when I launched it earlier this week, I saw this odd mix of font sizes. A colleague told me the same thing--GP used to display properly on his Surface Pro 4, but recently the fonts went haywire.
Notice the menus at the top are very large, while the text on the left panes is tiny.
Similarly, SQL Server Management Studio 2014 is a hot mess on high DPI displays. It was the SSMS 2014 issue that had me searching for a solution. And I came across this brilliant post.
http://www.sqlservercentral.com/blogs/spaghettidba/2015/10/14/ssms-in-high-dpi-displays-how-to-stop-the-madness/
Clearly the author has a pretty good understanding of the high DPI settings in Windows and figured out how to change the scaling method on a per-application basis using a manifest file.
I don't understand any of the mechanics, but I followed his instructions to import the extra registry key, then saved the Ssms.exe.manifest file to my machine. Like magic, SSMS 2014 displayed properly. The bitmap scaling on my displays at 175% is a bit fuzzy, but I'm okay with that, since it makes the applications much more usable. I can always try 150% or 200% scaling if necessary if the blurriness bothers me.
Since it worked for SQL Server Management Studio, I then wondered--could it work for Dynamics GP?
(Full credit goes to Gianluca Sartori for his article showing how to implement this fix--I didn't come up with any of this)
I created a Dynamics.exe.manifest file...and behold. GP launched just fine and rendered "normally", without the funky font sizes.
On a roll, I made a manifest file for SugarSync, and was pleased to see that it fixed SugarSync's scaling as well! SugarSync already had a manifest file, so I just edited it to add the additional settings from the SSMS 2014 sample.
I don't understand any of the settings in the manifest file, but it seems to be fairly generic and flexible, as I've just used the technique for 3 different applications.
If you want to give this a try, you do so at your own risk. If you don't know how to edit the registry or fix things if your computer goes haywire doing this, you should "consult an expert" to assist you.
Save this text to a file called "Scaling.reg".
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide]
"PreferExternalManifest"=dword:00000001
Once you have created the "reg" file, double click on it to import it into the Windows registry on the machine where Dynamics GP is installed.
Then save this text to a file called Dynamics.exe.manifest.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*">
</assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b">
</assemblyIdentity>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<ms_windowsSettings:dpiAware xmlns:ms_windowsSettings="http://schemas.microsoft.com/SMI/2005/WindowsSettings">false</ms_windowsSettings:dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
Then copy your new Dynamics.exe.manifest file to the GP application where the Dynamics.exe file is located.
So give it a try and let me know if it works for you.
Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics GP Certified IT Professional in Los Angeles. He is the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.
*This post is locked for comments