Window size and element visibility about booklibconnect

[MidCtrlDel]

I am also having this issue, I hope the attached log file can help! 👍
BookLibConnect.FormsTest_2022-02-05_001.log

[audiamus]

Are you running this on a 4k monitor with increased font size?

Screenshots are also welcome.

Unfortunately, I still haven't a clue what's happening here.

[MidCtrlDel]

I am in fact, yes. 3840x2160 with 250% scaling.

…

________________________________ From: audiamus ***@***.***> Sent: Sunday, February 6, 2022 12:24:56 AM To: audiamus/BookLibConnect ***@***.***> Cc: MidCtrlDel ***@***.***>; Comment ***@***.***> Subject: Re: [audiamus/BookLibConnect] Window size and element visibility (Issue #12) Are you running this on a 4k monitor with increased font size? — Reply to this email directly, view it on GitHub<#12 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXUFSYH5O6NA5U37VFYS22DUZYO4RANCNFSM5NELT52A>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[MidCtrlDel]

And this is what is what it looks like on my end (minus the fact that I obfuscated the titles)

[audiamus]

Right. It very much looks like an issue with the underlying .Net WinForms libraries. While they say, they would automatically adapt to high DPI scaling, there may be limits.

For the top left panel, its left anchor should be the left window border. But that appears to be ignored. The right anchor seems to be observed.

For the bottom panel with the splitter bars, their original positions appear not to be scaled upwards.

I tested on a hi-dpi laptop monitor, but only up to 150%, and it worked there.

[audiamus]

I have uploaded a new version of the test:
BookLibConnect.FormsTest.zip version 1.1

Regarding behaviour, the only change I made was to set High DPI awareness to the highest level. It was on a more basic level before.

I also added more log output for some of the elements ("controls"). They also spill out their absolute coordinates on the screen. Still in diagnostic mode.

[ninjapanzer]

@audiamus That makes sense, my Surface Pro 7 defaults to 200% scaling and when I adjusted that the buttons came back.

If I set the scaling to 100% and start the app it continues to work after being set back to 200% for that run. When I reopen at 200% those buttons are lost off the left side again in the download window.

[audiamus]

Did you try the latest version of our test program here?
Same effect?
In any case I would be grateful for a log file with that new version.

[ninjapanzer]

Same effect with the Test Program
BookLibConnect.FormsTest_2022-02-06_001.log

With Scaling set to 150%
BookLibConnect.FormsTest_2022-02-06_001.log

[audiamus]

Thank you. This gives me an idea what's happening to the buttons. (I haven't yet analysed the other log output.)

[audiamus]

While I could not find a pattern behind this behaviour, it appears that some anchor mechanisms for the Windows Forms controls (the visual elements) do not adapt properly to Hi DPI scaling modes at higher settings.

I have modified the hierarchy that contains the affected buttons and tested it for upscaling unto 200%. Works for me on that test system now where I could reproduce the problem before.

I also now explicitly set the splitter positions as they don't seem to adapt either.

New version:
BookLibConnect.FormsTest.zip version 1.2

[audiamus]

I have released Book Lib Connect 0.4 now, with the same modifications as in the test program. I hope it fixes the Hi DPI issues.