Solved TextBox rendering issue (possible a bug)

[GPGeorge]

Good call but I tried that already at 150% scaling and it still does it.

I do my Access stuff in VirtualBox. The version 7.1 has a bug in which the selected resolution is always off by 1 pixel, so you get weird resolutions like 1919x1199 instead of 1920x1200. Perhaps that throws something off in the renderer in which case it might not have something to do with Access itself but the underlying subsystem. I'll only know once VirtualBox fixes this annoying bug.

Please let us know how that turns out. I guess we could have saved a bit of Sturm und Drang, though, if you'd mentioned this bug in your VirtualBox VM at an earlier point in the discussion...

 

[AHeyne]

Good call but I tried that already at 150% scaling and it still does it.

I do my Access stuff in VirtualBox. The version 7.1 has a bug in which the selected resolution is always off by 1 pixel, so you get weird resolutions like 1919x1199 instead of 1920x1200. Perhaps that throws something off in the renderer in which case it might not have something to do with Access itself but the underlying subsystem. I'll only know once VirtualBox fixes this annoying bug.

How about 100% scaling? Same issue?

 

[The_Doc_Man]

While I don't claim to have seen the low-level code for video rendering & formatting, I would not hesitate for even a moment to say that it probably involves integer math and therefore some level of integer truncation for many of the scaling factors. Particularly when you start from something that will introduce ugly fractions to the mix, like 1919/1920 or 1199/1200.

 

[backcountryprogrammer]

Tested in A365 Beta channel. Same as everyone else here, the results are OK for me also

View attachment 116984
With 5 people all saying there is no issue, I really don't believe there is a bug here.

I had to chance to try it on 3 other computers (Win10). Idk what is going on but they all showed the truncated box as shown in my posted images.

Not sure why it works for you guys but not for me.

EDIT: I edited my initial posting to give more clear information.

 

[backcountryprogrammer]

Tested in A365 Beta channel. Same as everyone else here, the results are OK for me also

View attachment 116984
With 5 people all saying there is no issue, I really don't believe there is a bug here.

I noticed when the Text1 box gets the focus by clicking inside it, it works as expected. Try giving Text1 the focus by TAB'ing to it.

 

[Minty]

Have you tried removing any internal margin settings:

I have seen some odd effects, particularly on combo boxes, when these are anything other than 0 and coloured backgrounds are used.
They might be exacerbated by the scaling in the environment.

 

[backcountryprogrammer]

Have you tried removing any internal margin settings:
View attachment 117071

I have seen some odd effects, particularly on combo boxes, when these are anything other than 0 and coloured backgrounds are used.
They might be exacerbated by the scaling in the environment.

I can of course adjust the margins (or make the box larger) so the text doesn't become truncated. However, the problem is still there. The text in Text1 shifts vertically 2-3 pixels when the Text1 gets the focus by TAB'ing into it (so the text becomes auto-selected). Clicking into Text1 doesn't shift the text vertically for me.

Please read my first posting, I edited it to give more information.

 

[isladogs]

EDIT: It seem that the problem only shows for me if four conditions are met. borderwidth is not hairline, backcolor is set from the focus event handler and the textbox receives focus by TAB'ing into it and the text becomes auto-selected.

EDIT: I tried it on computers with and without HiDPI screens all showed the faulty behavior.

EDIT: First picture shows normal behavior because not all four conditions are met. Second picture shows the faulty behavior (all four conditions are met). The only difference between them is that in latter case the backcolor is set in the gotfocus event handler.

EDIT: In the attached DB, in order to show the faulty behavior, Text1 needs to receive the focus by TAB'ing to it (the text then becomes auto-selected).

Following your edits in post #1 shown above, I've retested your app
By tabbing to the second textbox, you may be somewhat relieved to know that I can now replicate your issue in a non-HDMI screen at 100% scaling

However, as soon as I press ENTER the text is correctly realigned

Agree with @Minty's comments. Reducing the margins, padding or border width all solve the issue
Basically I think your control isn't tall enough to handle the combination of settings you are using

 

[backcountryprogrammer]

I had to chance to try it on 3 other computers (Win10). Idk what is going on but they all showed the truncated box as shown in my posted images.

Not sure why it works for you guys but not for me.

Following your edits in post #1 shown above, I've retested your app
By tabbing to the second textbox, you may be somewhat relieved to know that I can now replicate your issue in a non-HDMI screen at 100% scaling

View attachment 117074

However, as soon as I press ENTER the text is correctly realigned

Agree with @Minty's comments. Reducing the margins, padding or border width all solve the issue
Basically I think your control isn't tall enough to handle the combination of settings you are using

Good to know. Thanks for testing this out. Yes I can work around this. However, it still smells like some bug in the underlying text rendering or the Text control. At this point it is what it is and chances MS will fix this are slim.

 

[isladogs]

Slim to zero . . .