I just noticed that my apps, when built for Windows, have trouble with fonts sizes. (They’re built with an older Xojo version from '14 or '15, not sure.)
When using “SmallSystem” for the font name, the font remains large, like for “System”.
When using either Win7’s or Win10’s font scaling (they seem to work differently), the fonts do not scale in my Xojo-made app but scale well in “regular” apps.
Are these known problems? Have recent Xojo versions tackled them?
Also, while working around the first problem is rather simple (by also setting an explicit font size instead of using “0”), I wonder if there are work-arounds for the second problem as well.
Well, the latest IDE certainly can’t handle the 150% on Win7 - in many places, the text overflows the button or label or editfield’s space, cutting off the text. In other places, no scaling happen, making the text hard to read because it’s too small.
Windows 7 way to scale is peculiar : it scales separately text and other controls, so it becomes very difficult for applications, not only the IDE, to deal with that.
AFAIK Windows 7 separate text scaling has never been supported by the IDE.
Windows 8 and Windows 10 are much more logical in their way to handle scaling, homogeneous for all controls.
Yeah, I had already suspected that Win7 and 10 use different ways. Okay, I’ll give up on Win7 then and test with Win10.
Damn - on Windows, when I change the font prefs in the IDE’s Options window, the code in the project window is not immediately updated, but only once I close the Options dialog. That’s not right, either.
Aha! When I run a test app made with latest IDE and enable HiDPI, then everything scales up by the 150% set up in Windows 7.
Which is exactly what I expected. Without building for HiDPI, the controls do not scale up, while the text in them does, leading to a cramped UI with cut-off text.
This suggests that the IDE is NOT using HiDPI mode. If it did, it might be actually usable on Win 7 (and 8) at 150% font scaling.
I also see that SmallSystem does NOT lead to a smaller fonts on Windows, ever. Which I find to be quite the bug, though I’m afraid that Xojo calls this an OS dependency and won’t fix this as “it’s always been like this”. Any other opinions on this?
“SmallSystem” acts as a meta font name in Xojo, just like “System” does, so it should map to a smaller font on all platforms, I’d say.
I also found that Win10 is slightly better at scaling 150%, but Xojo’s HiDPI mode screws that up a little in some places, again:
For instance, without HiDPI checked in the Xojo project, Win10 seems to let the app render everything at 100% (contrary to how Win7 did it), and then simply scales everything up to 150% afterwards. That way the dimensions of controls fit everywhere, but due to the odd scaling factor, we get ugly scaling artifacts, such as the fonts and lines all being a bit blurry.
OTOH, with HiDPI enabled, Xojo controls render properly at the higher resolution in Win10, making everything crisp.
However, some elements do not get upscaled as they should, such as the window title and the menubar. Which means they end up with very small text, making it hard to read again.
At 200% scaling, which is a more likely scaling with HiDPI screens, this issue is even more severe. The text become tiny. For a menu, that’s quite bad.
Is that a known issue? I’d think that must have been quite obvious in testing when HiDPI support was added, so why wasn’t this addressed?
Try multiple displays. It won’t switch scale factor.
I really don’t want to rant but I’m frustrated every day. So many things are half finished and called ‘Considered Beta’ so therefore barely usable (to me). Windows, ‘New’ Framework, 64 bit support etc.
I almost spend more time on all kind of workarounds than actually getting things done.
I take my hat off to people that were able to squeeze out an above average, good working, modern looking Windows project.
I am in the process of adapting an app already in the MAS to Windows, and it is a darn pain. I reported in another thread that TextArea.StyledText.RTFData is broken since apparently 2016R1, so I spent the better part of yesterday writing my own save/load styled text routine. Today I found out that popupmenu have erratic behavior when the user selects the same value as what is already selected. In popupmenu setting the font size, if I select twice 20, I end up with 10. So today I replaced that by a bevelbutton and a ListBox.
I bumped into DLL hell as well last week. Unfortunately, as the project has been created on Mac with 2016 and all pictures are image sets, I simply cannot revert to 2015R4.1 without major work.
Tomorrow I have to address printing that seems to be off as well.
Christophe bumped into the plain box window that has a white stripe on top. I reported that on July 20, 2015, over one year ago, and posted a three lines declare workaround. How difficult is it to implement ? It does not seem to interest anybody.
Only Windows 8.1+ supports this. You should get a ScaleFactorChanged event in 2016r2 or higher when the system settings or monitor changes DPI- please file a Feedback report if you don’t.
