I am having high DPI issues. I am mostly talking about text boxes. When the system DPI is put above 96dpi or 100% in windows my textboxes have the bottom half of their text cut off. I tried setting DPI aware to true and false in the exe manifest but I see no change at all.

Is there some way to lock the font DPI at the very least? All of my fonts are specified in points. I can change all fonts to pixels but this is a major pain and every font has a different Y ratio.
Re: high dpi issues
Post by Dan Teel on Feb 25th, 2016, 10:06pm

So if you're DPI is set to 144, then make the textbox x/y width/height 1.5 of its original size?

I dont know. Never messed with that stuff at all.

Edit: Or, you can calculate what the font size should be to match what it would be at 96 DPI. So if the DPI is 144, then divide the original font size by 1.5, and then use that as your new font size? Not sure man Re: high dpi issues
Post by Stefan Pendl on Feb 26th, 2016, 12:46pm

Dialog type windows scale most things except graphics based on the DPI settings.

Stef that is quite a hack! It works. Deadlines deadlines.... sigh. I have 1 window with a small text editor like box in it. I can externalize it, luckily it's pretty trivial. At least this way I don't need a complete re-design or a regex I might regret later.
Re: high dpi issues
Post by hooshnik on May 10th, 2016, 4:10pm

I found a bug with this hack. I used lucida_console at 18 points and LB is clipping the text before the end of a statictext at 150% DPI mode. I know it was not going on the next line as I gave it 150 extra horizontal pixels or so just to display the letter 'e' at the end of the last word and it fails. Going to 16 points was enough to solve the problem for that case but it's still annoying to have a point limit.
Re: high dpi issues
Post by hooshnik on Jul 25th, 2016, 5:02pm

This hack is not working for a system DPI with greater than 125% on windows 7. Does anybody know of a workaround? It doesn't make sense to manually resize every single control and font for all windows. Can't test 150% on windows 10 yet but I'm working on it.
Re: high dpi issues
Post by Jim Hiley on Jul 26th, 2016, 12:32am

I just realized I'm going to have to use scan loops for every single window if I want to support a system DPI greater than 125%. Type dialog is useless when DPI is set above 125%. If my user leaves a window open and then opens another one, that one has to end up inside a scan loop. It must look for the enter key being pressed in the first window if it is supposed to support branching on the enter key being pressed. But how can that work? I'll have to see which window has focus.

Tedious. I can see no other solution to this.
Re: high dpi issues
Post by Rod on Aug 2nd, 2016, 01:59am

There are examples posted of how to discern which window/ control has focus with an API call. I think it is GetFocus you should search out. But it may not be be a complete fix.

So we have multiple windows with multiple font sizes? Perhaps some short code showing us all what you are up to might get more specific help and advice.

You have said elsewhere that you can have up to twenty pop up windows, what is the users take on that? Are some of the pop ups similar in appearance?
Re: high dpi issues
Post by CarlGundel on Aug 2nd, 2016, 08:23am

This is not a simple matter. Scaling a user interface can be tricky and it isn't well handled by Windows or by the Mac OS.

It's interesting to see people use their ingenuity to solve these problems. Gives me ideas.

I just realized I'm going to have to use scan loops for every single window if I want to support a system DPI greater than 125%. Type dialog is useless when DPI is set above 125%. If my user leaves a window open and then opens another one, that one has to end up inside a scan loop. It must look for the enter key being pressed in the first window if it is supposed to support branching on the enter key being pressed. But how can that work? I'll have to see which window has focus.

Tedious. I can see no other solution to this.

Can you post a real simple example program? Not the scanning stuff, just of a window that doesn't scale well?

The function I posted is not a hack, it is the only way to reliably get the scaling factor from the DPI settings.If it doesn't work for you, then you are not scaling every aspect of the window and its controls.You need to scale not only the size, but also the position of windows and controls.In addition you need to scale the fonts, but there is a problem if Windows doesn't find the correct size of the font and therefore uses an approximation, mostly it is the next bigger font.You may want to create the scaling based on the dialog-base-units too, but I think I skipped that due to being more complex.If you use a window of type dialog, the scaling is done by Windows and you don't have to scale as much as with a regular window type window, see http://basic.wikispaces.com/HelpSearch_Pendl_newRe: high dpi issues
Post by hooshnik on Aug 2nd, 2016, 5:04pm

The function I posted is not a hack, it is the only way to reliably get the scaling factor from the DPI settings.If it doesn't work for you, then you are not scaling every aspect of the window and its controls.You need to scale not only the size, but also the position of windows and controls.In addition you need to scale the fonts, but there is a problem if Windows doesn't find the correct size of the font and therefore uses an approximation, mostly it is the next bigger font.You may want to create the scaling based on the dialog-base-units too, but I think I skipped that due to being more complex.If you use a window of type dialog, the scaling is done by Windows and you don't have to scale as much as with a regular window type window, see http://basic.wikispaces.com/HelpSearch_Pendl_new

Hi Steph.

I noticed here you are pinning the DPI to a maximum of 1.25 because you know about the issue with dialog windows? Am I correct?

GetScreenScaleForDialog = min(1.25, ScreenScaleTmp)

As soon as you go to 150% on a dialog (windows7) the text starts to get clipped.

But anyway there is a better solution IF WE WANT TO RELY ON WINDOWS. We can change all fonts in the program to pixels regardless of whether it's a dialog or window. That way a scan loop wouldn't be needed.

As an aside... if we do not want to rely on windows and do everything manually (which according to some comments (rumors) about windows 10 anniversary edition that just came out) because right now at 225% scale factor on windows 10 explorer buttons look readable but very big and ugly compared to non-microsoft apps. I suppose Microsoft will fix this... but I wonder if it has anything to do with LB dialog DPI problems?

Is dialog box units really that great compared to just changing the fonts to pixels? This is getting complicated! Are you talking about this?:

In addition you need to scale the fonts, but there is a problem if Windows doesn't find the correct size of the font and therefore uses an approximation, mostly it is the next bigger font.

Ok buttons are displaying correctly. I was confusing some special code I had written for dynamic window generation and forgot to convert points to pixels.

However I am seeing the problem above that Stefan said. It is happening with ms_sans_serif and lucida_console with statictext. So really there is nothing new under the sun here.

What I will do is look at the dpi scale factor and somehow try to scale back the points if I see it getting high so that windows doesn't choose the next highest font. Why did Microsoft do that? Why didn't they pick the next lowest instead?!

As for what Rod said I don't understand. Some people have vision problems or they have to look at a monitor that is far away. That's the whole point of magnifying things. I have a monitor myself that is 25.5" and goes to 1920x1200. At the resolution I can't read a damn thing if I use applications at 96 DPI. I end up bumping down the resolution to 1680x1050 on linux as DPI support on linux is behind compared to windows.

Rod do you mean give the user the option of changing the DPI or not for only the program? Also about posting that code. I was asked once yes, but the situation changed. Do you still want me to post the code in light of what Stefan and I have just confirmed?
Re: high dpi issues
Post by hooshnik on Aug 11th, 2016, 3:11pm

I have a WIP dialog window showing the (known) problem with the fonts. Using "font lucida_console 12"

I was not aware of any problem with 150%, the program was just written on a screen with 125%, if I remember correctly.

I don't know what you mean lol. I went and modified the screenshot window with the font I was using but I did it before you posted this. Are you saying to just avoid point sizes that cause this problem with type dialog?

In other news I have decided to dump the idea of using dialog windows everywhere. I will leave it up to the reader to draw their own conclusions.
Re: high dpi issues
Post by Stefan Pendl on Sep 3rd, 2016, 05:01am

Dialog type windows are always scaling text and controls correctly on their own, which is done by Windows automatically for these types of windows.You only need to scale content of any other window type.The exception is graphics, which must be scaled in any type of window, despite of being a dialog type or not.
Re: high dpi issues
Post by Rod on Oct 23rd, 2016, 07:50am

Having reread this a couple of times I think the problem is that when scaling, Windows "may" replace the chosen font with one of a larger size than you would expect. So the answer is to allow some white space for this to happen. So make the buttons and controls a little wider than you would normally. Perhaps some fonts will scale better than others.