Scaling issue - DPI aware activates itself and break layouts

[Andre]

@helpy: thank you for this links - much stuff / good explanations about a complicated (at least for me) topic!

@BarryG: the reported 'bug' is specific to the Windows OS - if Fred can confirm, that there is no error in the related PB library, then he would comment this report and move it to the 'Windows' forum section... so don't worry

[helpy]

@helpy: thank you for this links - much stuff / good explanations about a complicated (at least for me) topic!

I am glad that the links were informative. I have just had a quick look at it myself and thought it might be helpful. I have hardly gotten into this topic myself and have hardly used DPI awareness before.

@Andre: Viele Grüß aus Niederbayern ins Erzgebirge ,
Guido

[Andre]

@Andre: Viele Grüß aus Niederbayern ins Erzgebirge ,
Guido

Thank you, many greetings back

[Saki]

Hi all
Since the last Windows Update to 2004 there are massive problems with codes that are not DPI aware,
or even with older, already completed codes.
After starting in the PB interface these are incorrectly scaled.
This concerns all scales >100%.
On a 4K monitor, it's a disaster.

It look as sample so :
Preseted Windows Scaling 225%
Resulted damaged output : Window, Canvas, Gadgets 100% - Text 225%
With this resulted output developing is no longer possible

Scaling errors at 125% are only 25%, which, depending on the code, often isn't even noticeable, but can also be much too much.
If an exe is created and started separately, everything is OK.
So it's the PB user interface where something is wrong with the DPI aware.
It is no longer possible to work sensibly with it.
The only way out is to code only DPI aware, or not to use scales >100%, which does not solve the problems with older codes.
You can't just convert codes to DPI aware.
Depending on the complexity of these codes, it can be simple or horrible.

Best regards Saki

[Rinzwind]

Apple did handle this much better and way more practical. Screen points were never the same as physical screen pixels even if they were. The whole Cocao library handles this nicely. Their hi dpi screens doubled width and height pixel density. Makes easy math and clear results. Gui apis should never address pixels directly. Bad win32... do not leave it to the app programmer to calculate screen pixels...

[Saki]

The complete reinstallation of Windows eliminates the last described error.

This had to be tried, because there was the suspicion that it could help.

It is now again so, that only the extended scales are defective.
You can live with that, but it is still a very bad thing.
Misscaling does not give any indication what is going on.
It doesn't matter if a separate exe is started or from the UI, both are broken.

The mechanism to detect when a scaling is faulty is
check if the Windows process is DPI aware and at the same time the status in the PB compiler options.
If the compiler option is deactivated and the process DPI Aware, these false scaling will occur,
which in itself seems logical in this case.

However, it would be really helpful to check the status of the activated DPI aware in the compiler options via a PB constant.

Best Regards Saki