Hello everyone, it turns out that the units for the particular datawindow in question was set to pixels! and not powerbuilder! units.  This fixed everything..

Thanks for all the help

Actually its not the font size that is the issue its the x,y position and the lengths of the fields that are the problem...  they are much small on the datawindow than on the window itself.  The fonts and text show up normally...

Thanks a lot for the information, its very helpful.  We will give it a try.

Buck

This page shows how to make your app DPI aware using the manifest. It can also be done with a function.

https://docs.microsoft.com/en-us/windows/win32/hidpi/setting-the-default-dpi-awareness-for-a-process

Both Chris and Armeen bring up excellent points that I agree with wholeheartedly.

Beginning in Windows 8, I believe, and incrementally since then, Microsoft has made supposed "improvements" (let's play nice and just call them "changes") in the area of DPI (dots per inch) scaling. New API's have been introduced which can permit an app to become "DPI aware". As far as I know, PB does not yet utilize these new API functions, so a PB app is still unable to dynamically adjust to non-standard (anything other than 100%) DPI scaling.

This MAY be what is affecting the placement of the "Find" child window, for example. I don't know how you are determining the placement of that window at execution time, but you may wish to examine the logic more closely.

Chris' comment is spot on and may very well be why you see text labels being cropped. As a rule, I make it a point NOT to define the size of text DWObjects too restrictively to try and avoid the potential for cropping. You have a lot a fields packed tightly and this can be a challenge.

At a point in time long ago, Microsoft used the Arial type face extensively, then later moved to Tahoma and more recently switched to using Segoe UI. You may wish to test alternatives to Arial in your application.

Best regards, John

Hi Olan, See if your scaling on Windows 10 is set to 100% instead of higher?

Hi Buck;

 Also, remember that the DWO gets its font rendering from the App user's "default" printer. So you might want to do a test & change that on the machines that render poorly to see if that makes a difference both in clarity & drawing speed. Food for thought.  ;-)

Regards ... Chris