Prevent wxWidgets app from scaling sizes on higher dpi

1
votes

I'm writing a wxWidgets (3.1.0) app that is supposed to work on windows and mac. On windows when i set the scaling of the text to more than 100% the sizes of my controls get all messed up. I have a dpi manifest that says my app is dpi aware. I also set the font pixel size on my dialogs and that works to some extent. When i set the size of some element from code it is resized to that pixel size which is what i need, but any size that is set in the xrc file gets scaled up. Also when i try to reduce the size of any wxSpinCtrl it can be reduced normally to some point but then only the text box gets smaller and the buttons remain unproportionally large. So is there a way to tell my app not to scale any sizes and just let everything be exactly the same pixel size as it would be on a normal dpi (despite the fact that my app will look small on higher resolutions)?

1
wxwidgetsdpi
did you try to remove dpi awareness from manifest file? – Igor
@Igor If i remove the manifest then windows uses its default zoom which makes everything look blurry – Milan
This is a very strange question, why exactly would you consciously want your program to look bad on high DPI screens? The real solution is to solve the problem, whatever it is. Unfortunately "all messed up" is not precise enough to understand what is it exactly. – VZ.
@VZ. By messed up i mean that if i set something to be 300 pixels wide, it will be 375 pixels wide on 125% scaling and 450 pixels wide on 150% scaling, but i want it to be 300 pixels wide all the time regardless of the scaling – Milan
This is not "messed up", this is "scaled correctly" and if this is all that happens, I still don't understand why is this a problem. – VZ.

1 Answers

0
votes

There is no way to prevent the proper scaling from being applied using wxWidgets API and I don't think this is going to change because it just doesn't seem to make any sense.

However rebuilding wxWidgets with wxHAVE_DPI_INDEPENDENT_PIXELS defined should trick the library into thinking that the underlying graphical toolkit already scales the pixel values and so prevent it from doing it on its own. I've never tested this but, AFAICS, this should result in what you want.

Nevertheless let me reiterate that what you want is totally wrong and the real fix for this problem is to explain it to whoever decided to do it.