I've had this problem for several years and posted about it before and didn't get a resolution.

It is a real PITA and I've now run into an issue where I cannot save Preferences changes because of it.

The problem is that the font size and spacing on everything in my designer is way to big. I have this problem with 5.3.3 and with a freshly-installed 5.5 (I think the problem goes back to when LLBLGen used a new GUI framework a few versions ago).

I've attached a typical issue that the sizing causes: I'm in the preferences dialog and there is a scrollbar on a div INSIDE the dialog but that div overflows the vertical bounds of the dialog even when I maximize the dialog. And the dialog itself doesn't have vertical scrollbars so I have no way to reach the content at the bottom of the div. I'm trying to experiment with the "Text Editor" Preferences to change them from Consolas, 10pt to something smaller to see if this will have any effect on my problem. But I can't get at what I suspect must be a Save button at the bottom of the dialog and so when I dismiss the Preferences dialog, my changes get lost.

I have another bug report about not being able to see custom attributes that I added in the Code Generation tab of several entities. I did this a few years ago on an LLBLGen project that I've started modifying recently. I wonder if I can't see them for the same reason that I cannot see the Preferences dialog Save button.

My computer is nothing exotic. Typical developer set up. Surface Book 2 with 2 external 1920x1080 monitors. Scale and Layout settings in Windows Display Settings is set to "100% (Recommended)". I run all kinds of apps (VS, VS Code, etc.) and none of them have 'magnified' UIs like the LLBLGen Designer.

Help! This is a showstopper. I'm editing my llblgenproj manually for now but will be completely stuck soon!

Hmm. this is really odd! We don't do any scaling ourselves, so this is weird.

Ok, close the designer. then go into C:\Users<your user>\AppData\Roaming\LLBLGen Pro

and delete the guistate.xml and panelstate.xml files.

Also make sure in the llblgen pro installation folder, the llblgenpro.exe.config file, that you have EnableWindowsFormsHighDpiAutoResizing set to false (it's false by default, but perhaps you changed it / someone changed it).

Then start the designer again. It should revert to the default UI/setup. Please let us know if this solves anything.

If you use any other winforms app do you have the same problems in those?

We use DevExpress controls throughout the designer and never have had any user report this problem. Nevertheless we'll try to get to the bottom of this!

It might be related to a change in windows 10, but not sure. Our forms are all scaled using 'Font' as that worked fine for windows 7/8. On windows 10 it might not be (although we don't see problems on our windows 10 boxes).

See: https://stackoverflow.com/questions/37189430/windows-forms-application-on-windows-10-not-scaling-properly

If what I suggested doesn't help, we'll create a test version with dpi scaling for you to test on Monday. The .NET winforms documentation suggests however that 'Font' (which we use) is the best choice.

Deleting those guistate and panelstate files didn't help.

However, I did some experimenting and I think I know what is going on and I have a workaround.

My laptop's screen's resolution is much higher than my dual monitors at my desk. So when I work using the laptop screen, my Windows profile has the Scale and Layout setting set to 200% (as opposed to 100% for the attached monitors). It looks like if I use LLBLGen on the laptop screen, LLBLGen 'remembers' that scaling and uses it next time I launch LLBLGen even if I launch it with my attached monitors.

The fix is to exit LLBLGen, go to Windows Display Settings, set it to something other than 100%, save and reboot, go back and set it back to 100% and then start LLBLGen again. That fixes the problem.

So it is either a Windows bug or a bug in the UI framework that you use.

So I have a workaround. It's a little painful since I switch between using my laptop standalone and docked with monitors almost daily, but I can live with it for a while.

If you need anything from me to help fix the issue, let me know.

Emmanuel wrote:

Deleting those guistate and panelstate files didn't help.

However, I did some experimenting and I think I know what is going on and I have a workaround.

My laptop's screen's resolution is much higher than my dual monitors at my desk. So when I work using the laptop screen, my Windows profile has the Scale and Layout setting set to 200% (as opposed to 100% for the attached monitors). It looks like if I use LLBLGen on the laptop screen, LLBLGen 'remembers' that scaling and uses it next time I launch LLBLGen even if I launch it with my attached monitors.

I feared as much. Thing is: we don't try to remember any scaling, so that's a bit of a weird thing. Perhaps the DevExpress controls try to remember it for next time, but then again, that sounds silly as it might have changed and you have to check anyway. I do know that windows forms GUIs don't act well when you have them running and change scaling options. You have to sign out to make them stick. (At least that's what we had to do when we tested high DPI issues on windows 10).

The fix is to exit LLBLGen, go to Windows Display Settings, set it to something other than 100%, save and reboot, go back and set it back to 100% and then start LLBLGen again. That fixes the problem.

So it is either a Windows bug or a bug in the UI framework that you use.

I think it should be sufficient to close llblgen before you connect your monitors, as windows will change scaling settings on the fly when you connect your laptop to the monitors but the windows forms apps running at that time won't be updated, they'll keep the original settings. Could you try that please?

So I have a workaround. It's a little painful since I switch between using my laptop standalone and docked with monitors almost daily, but I can live with it for a while.

If you need anything from me to help fix the issue, let me know.

Also could you check if have .net 4.8 installed and if not, could you try that too? It comes with more dpi related fixes. If you're not sure, the installer will tell you (https://dotnet.microsoft.com/download)