Formsize on multimonitor system with different DPI settings

VCL TMS VCL UI Pack
1

I use the tFormsize to save and restore Form Positions (mostly without sizes). I see a very crazy problem with following setup:

  1. Monitor (primary) with 100% = 96dpi
  2. Monitor with 125% = 120dpi

I start my Form, it opens on primary monitor, now i move it to second monitor, it automatically resizes because of form.scaled=true. Now i close the form and the form get's stored in the registry.

After opening the form again, it is opened on second monitor with 125%, i see all elements like tEdit are scaled but the form itself has the width and height from 96dpi. so the width and height is on second monitor too small. Now i can move the form again to Monitor1 and it gets scaled with false width / height.

Possible that we have to add a manual DPI calculation before MoveWindow ?

mon:=Screen.MonitorFromPoint(Point(ARect.Left + ((ARect.Right - ARect.Left) div 2), ARect.Top + ((ARect.Bottom - ARect.Top) div 2)));
if mon.PixelsPerInch<>(owner as tform).PixelsPerInch then begin
	aRect.Right:=aRect.left+ MulDiv(aRect.Right-aRect.Left, mon.PixelsPerInch, (owner as tform).PixelsPerInch);
	aRect.Bottom:=aRect.Top+ MulDiv(aRect.Bottom-aRect.Top, mon.PixelsPerInch, (owner as tform).PixelsPerInch);
end;

(Owner as TForm).BoundsRect := ARect;
MoveWindow((Owner as TForm).Handle, ARect.Left, ARect.Top, ARect.Right - ARect.Left, ARect.Bottom - ARect.Top, true);
2

I have seen 'crazy things' with FormSize if I fail to ensure that the window position is 'poDesigned'. And you don't actually confirm that your application is built with a PerMonitorDPI manifest, which is also important.

3

Hi Tim, yes my application is build with PerMonitorDPI. I tried Monitor and Monitor2 settings but same results.

And yes, in my current case the Position is poScreenCenter

4

Then I suggest you at least try poDesigned. Look in the Formsize source, it makes a change to how the component operates, so it is worth it. You may not find that it improves matters in your case, but it will take a different path.

5

Does also not help. I have changed the code in Formsize to "if not savesize than only set form.left and form.top" and the problem is gone ;-)

I think TMS has to develope and optimize the tformsize component for additional functionality with

  • centered forms
  • mdi forms
    and i.e. setup poDesigned automatically ...
6

We could see shortcomings in the area of dealing with different DPI scenarios and have applied improvements. These improvements will be included in the next release.

1 Like
7

I find a regression in these changes (Formsize 1.4.3.0). The restoring works correctly for the main form, but when you save a subsidiary form or custom dialog, the position is saved incorrectly, so that the form is always restored on the same monitor as the main form, even if you have closed it on the other monitor. I have reverted to the previous version of this component, which I found no issues with. We always set poDesigned on a form which uses TFormsize, however. And I am aware that getting all this right in all circumstances is horrendously complex, especially when combined with the different bugs and fixes in each VCL release.

8

Yes, same problems here, we switched to previous release as base with our own add for mdi-forms etc.

9

I cannot see how this update could affect or change a form position (Top/Left coordinate).
The change done in the code clearly only affects the form width/height to take monitor DPI in account, i.e. the width/height values saved and loaded. It does not change the form Top/Left at all.

10

Thanks for looking into this. I agree that the changes did not affect top/left, but nevertheless I described the symptoms I saw, which went away when I reverted. I believe that somewhere in the VCL there may be a (recently added?) dependency on the parent window position when creating a form, and it is possible that your changes for width/height may have introduced a timing or order-of-operation difference which has exposed this. Certainly this VCL issue seems to affect the Get/Set WindowPlacement method (not used in Formsize) of saving form positions, which now results in a different position/size for a main window depending on the monitor used for the shortcut or explorer window which started the process, when I experimented with it.

There is also another issue with the changes in Formsize which I did not mention earlier: lack of compatibility with a size saved previously. I found in early testing that there are monitor-dpi conditions in which a user who updates our application finds a huge window spanning both monitors on the first use of the new build. This was another reason not to use the new version of this component. Although it does not persist, for it to happen with multiple programs would not have looked good. There should have been a version flag of some sort in the saved data to avoid this problem, but it may be too late now.