Closed NigelGomm closed 10 months ago
I need more information to be able to look into this: steps to reproduce, screen shot of what it looks like, etc.
(Part of the problem is that things are exacerbated by my dpiawaremanager code increasing widths and fontsizes by 1.75.)
Just change monitor scaling in your windows control panel settings to 175%
This is with your original .calculatewidth() in place with no monitor scaling
This is same but with monitor scaling at 175% (and my dpiawaremanager switched off so no change to widths or fontsizes)
now here it is at 175% with my txtwidth*fontmetric code. (still with my dpiawaremanager switched off)
and again but with dpiawaremanager code on.
n
and using oGDI.measurestring() with my dpiawaremanager increasing widths and fonts by 1.75 does this
n
I can't reproduce that. Here's a ribbon on a monitor at 3840x2160, 125%:
Here it is at 175%:
(Note that for some reason GitHub is showing these images as the same but the 175 image is quite a bit larger, but text size and positioning is the same relative to 125.)
I was able to reproduce it by creating a DPI-aware manifest file and running from an EXE. I'll see what I can do about it.
This is fixed in the latest build.
sorry... i'd forgotten about the manifest.nOn Dec 23, 2023 5:41 PM, Doug Hennig @.***> wrote: This is fixed in the latest build.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
i suspect it's the hard coding of cnFACTOR ?
for now i have replaced the call on .measurestring() and subsequent use of .nwidth in my copy with variations on
TXTWIDTH(THIS.CAPTION,THIS.lblbutton.FONTNAME,THIS.lblbutton.FONTSIZE) * FONTMETRIC(6,THIS.lblbutton.FONTNAME,THIS.lblbutton.FONTSIZE)
and that seems to be working in testing so far.I can post my new versions of .calculatewidth() for sfribbontoolbarbutton, sfribbontoolbarbuttonhorizontal and sfribbontab but suspect you'd prefer a gdi solution?
n