1. Joon Choi
  2. PowerBuilder
  3. Friday, 6 August 2021 19:58 PM UTC

Thanks to everyone who responded to running PB2019 on Windows Server 2008 R2.  I have another hardware issue..  This involves running the same code on a Windows Server 2012 vs running locally on a Windows 10 workstation...  The Windows Server 2012 version looks fine, the Windows 10 version looks like the fonts are larger and therefore are truncated, also a small child window has its y location off by a bit.  The resolution in both cases is 1920*1080.  The font is TT Arial size 10

The Windows Server 2012 version, looks fine

Same window running on Windows 10, You see the text takes up more space and the small child window y location is off a bit

Any ideas?  Maybe a different font?

Joon Choi Accepted Answer Pending Moderation
  1. Wednesday, 11 August 2021 15:08 PM UTC
  2. PowerBuilder
  3. # 1

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

Comment
  1. Armeen Mazda @Appeon
  2. Wednesday, 11 August 2021 15:34 PM UTC
Thanks for sharing the solution!
  1. Helpful
There are no comments made yet.
Joon Choi Accepted Answer Pending Moderation
  1. Monday, 9 August 2021 19:47 PM UTC
  2. PowerBuilder
  3. # 2

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...

Comment
  1. John Fauss
  2. Monday, 9 August 2021 21:44 PM UTC
Please re-read Chris' original response. Any change in the user's default printer (and a new version of the printer driver used by the OS could potentially be qualify as a change) may affect the appearance (such as X,Y positioning and inter-character spacing) of the visual content within a DataWindow. The appearance of visual objects outside of a DataWindow are rendered by Windows, Inside of a DataWindow, the visual objects are rendered by the DataWindow engine and this is affected by the user's default printer..



Please also note that if do not find the responses offered by the members of the Community helpful, you always have the option of opening a Support Ticket.
  1. Helpful
There are no comments made yet.
Joon Choi Accepted Answer Pending Moderation
  1. Monday, 9 August 2021 16:23 PM UTC
  2. PowerBuilder
  3. # 3

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

 

Buck

Comment
There are no comments made yet.
Roland Smith Accepted Answer Pending Moderation
  1. Sunday, 8 August 2021 14:50 PM UTC
  2. PowerBuilder
  3. # 4

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

 

Comment
There are no comments made yet.
John Fauss Accepted Answer Pending Moderation
  1. Saturday, 7 August 2021 18:11 PM UTC
  2. PowerBuilder
  3. # 5

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

Comment
  1. John Fauss
  2. Sunday, 8 August 2021 21:00 PM UTC
It's good to hear from you, Chris! The commercial app I support also uses Tahoma 8 point, with great results. In our case, we have no immediate plans to move to Segue UI, but I wanted Buck to be aware of what the elephant in the room is doing and allow him to do what he wants to with that information. Thanks for sharing!
  1. Helpful
  1. Joon Choi
  2. Monday, 9 August 2021 19:49 PM UTC
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...
  1. Helpful
  1. Joon Choi
  2. Wednesday, 11 August 2021 15:09 PM UTC
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.
  1. Helpful
There are no comments made yet.
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Friday, 6 August 2021 20:22 PM UTC
  2. PowerBuilder
  3. # 6

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

 

Comment
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Friday, 6 August 2021 20:19 PM UTC
  2. PowerBuilder
  3. # 7

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

Comment
  1. Chris Pollach @Appeon
  2. Sunday, 8 August 2021 18:12 PM UTC
PS: since Windows server 2016, the "server" based O/S's use the W10 Kernel. Thus why W2016, 2019, etc render like W10 and W2008, 2012 do not.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.