Not respecting Windows DPI setting 2016r1.1

I realize there are issues with the HiDPI setting in the latest release with it set to ON, but the documentation ( http://developer.xojo.com/hidpi-support ) states the following “When SupportsHiDPI is turned OFF, the framework will continue to work the way it did before.” I’ve discovered this not to be true and the latest release of XOJO is now NOT respecting the DPI settings (say 125%) a Windows user may of had previously set.

I have the Supports HiDPI setting off in my Build Settings, but when I run the app it everything stays the same size. No longer respecting the Windows DPI setting. In version prior to 2016, this was not the case.

Has anyone else come across this issue?

Thanks!
Tom

Just verified this myself.

Why is XOJO not respecting my DPI setting if I leave HIDPI setting off (the default)??? Now, instead of the application’s objects increasing in size based on the DPI setting (125%), it doesn’t change at all. This will not fly well with many of my users who change their DPI settings due to visibility issues. Hopefully, we can get this fixed ASAP.

Can someone else confirm that this is a known issue in 2016r1.1?

A sample simple project would be nice so we’re all testing off the same code. Pop one up and I’ll test it in the next few minutes.

Also what version of Windows are you testing in?

Windows 7, but I doubt it matters.

You can use any example project that is included with XOJO. I used Desktop - Controls - ControlSets example project. The key is to turn OFF Supports Retina / HiDPI setting in the Shared Build Settings. Run it at 100% DPI take a screen shot or just look at it, then change the DPI to 125%, log off and login, and run it again. The form and all of it’s controls will look the same as the 100% setting. We cannot use the HiDPI setting turned ON. There are two many bugs. ( key is to make sure the setting is OFF )

Prior to the availability of this new setting, the form and it’s controls respected the Windows DPI setting. According to documentation the program should of worked the same as the previous version of XOJO. “When SupportsHiDPI is turned OFF, the framework will continue to work the way it did before.”

Hello guys. I am worrying about this quite long and I have posted several times on this forum. Nobody seemed to be interested but this issue makes that you have to stick to max version 2015 r4.1 for windows desktop projects.
This should have been comminicated better. I believe there were too mutch changes to keep things 100% backwards compatible. .

Has anyone seen this on Windows 8.1 or Windows 10? Is there a Feedback case about this?

Yes, a few days ago somebody created a feedback about this issue. I am on my phone so can’t lookup now, but it’s just 3 days ago.

Think even on windows 10 it’s a problem.
I was yelling on it allready on this forum when 2016r1 was in beta.

Ah, there’s a Beta case filed about this.

It’s <https://xojo.com/issue/43886> if anyone wants to sign on.

Thanks for putting in the Feedback Case on this.

While some may think it’s trivial, It’s a pretty significant issue for some of our older users that wish to see their screens in a larger format and have used the DPI setting for years. Hopefully they will honor their documentation and make it work the same as the previous version of XOJO when the HiDPI setting is OFF.

Is it somehow possible to read that setting from the OS?

Sorry for the delay in coming back to this thread, I cannot replicate this on windows 10 v2016 r1.1

Desktop is at 200%, HiPDI build setting is OFF

Even dragging the window between a 200% screen and a 100% screen causes the form to resize correctly.

I would not hijack <https://xojo.com/issue/43886> if you see the problemm, we’re talking about a non-beta version here so non-beta users can’t input to that thread, post your OS and version of Xojo in here for starters. Here say or conjecture is a waste of time, don’t speculate, accumulate evidence. So many posts with “I see it, I see it” and no additional info given, post versions and OS or you’re just wasting everyone’s time.

“I see the problem”, what problem, does the windows frame stay the same size too or just controls?

Post a screenshot if possible, some say that is says > 1000 words :wink:

When you test DPI settings, make double sure you log off between settings changes before reporting confirmation/screenshots.

Sorry to sound funny, its just basic debugging 101 here.

[quote=266910:@]I cannot replicate this on windows 10 v2016 r1.1
Desktop is at 200%, HiPDI build setting is OFF[/quote]

Problem manifests on Windows 7

Windows 7 has a different way of doing scaling than Windows 10. Non HiDPI apps see Windows 10 scaled screen as a lower resolution. In Windows 7 I don’t think it ever worked.

If you are part of the Beta program, please try and verify the fix for this case in the next Beta that is posted.

Indeed! I think Michel and I worked on an issue with his screen scaling app and Windows 7, and it worked inconsistently – but only with Windows 7. It seems to work ok with Windows 8.1 and Windows 10. Have no idea why MS would do this sort of thing, creates chaos for apps that want to adapt to different display types and sizes.

I’ve not tested this in Win7 yet so I can’t say with much certainty, but Windows 7 was released in 2009 before HiDPI was even considered. Whatever has been done with Win7 has been done retrospectively. If its just a problem with Xojo, then its not an MS problem :slight_smile:

From what I remember, the problem is that Xojo apps have no direct way to enforce the Windows 7 Text scaling setting. I am sure there is somewhere, probably in the registry, the scale of text, which the app can pick up and enforce. But the process would have to be coded into the app.

I meant as far as Windows enlarging and shrinking things so that stuff fits properly at any system text size, even using something like RubberViews or Elastic Window. I’ve confirmed that Visual Basic 6 has the same issue, but ONLY with Windows 7, for the most part anyway. Just plain annoying.