View Issue Details

IDProjectCategoryView StatusLast Update
0035231LazarusLCLpublic2019-10-06 12:48
ReporterPeterX Assigned To 
Status newResolutionopen 
Product Version2.0 
Summary0035231: High DPI - value "DesignTimePPI" is different between *.lfm file and Object Inspector

I often move my projects between two Windows PCs, one with 100% scaling, one with 125% scaling.

Size of elements like TPanel and/or the whole window size can be different
when opening the project on my 100% scaling's and 125% scaling's PC.

I found out that value "DesignTimePPI" is sometines different between *.lfm file and Object Inspector. Example application can be found here:,44192.msg310480.html#msg310480
Steps To Reproduce- change size of main window on one PC
- save project and close
- move the project to another PC (or change scaling and reboot ..)
- open projectz and check value "DesignTimePPI"
  1) in Object Inspector
  2) in *.lfm file
TagsNo tags attached.
Fixed in Revision
Attached Files


related to 0034841 new AnchorDocking: Loading layouts does not consider HighDPI scaling 


Pascal Riekenberg

2019-03-15 12:26

developer   ~0114834

Similar to 0034841. There is patch for making the form modified if the DesignTimePPI changes on opening in the ide.

Juha Manninen

2019-04-05 11:06


sourcefilemanager-1.patch (1,378 bytes)   
Index: ide/sourcefilemanager.pas
--- ide/sourcefilemanager.pas	(revision 59892)
+++ ide/sourcefilemanager.pas	(working copy)
@@ -3798,9 +3798,7 @@
-    // set all modified to false
-    Project1.ClearModifieds(true);
     IDEProtocolOpts.LastProjectLoadingCrashed := False;
@@ -6024,6 +6022,8 @@
             DsgControl.AutoAdjustLayout(lapAutoAdjustForDPI, DsgControl.DesignTimePPI, Screen.PixelsPerInch, 0, 0);
             DesignerProcs.ScaleNonVisual(DsgControl, DsgControl.DesignTimePPI, Screen.PixelsPerInch);
+          if DsgControl.DesignTimePPI <> Screen.PixelsPerInch then
+            AnUnitInfo.Modified := True;
           DsgControl.DesignTimePPI := Screen.PixelsPerInch;
           DsgControl.PixelsPerInch := Screen.PixelsPerInch;
@@ -6041,6 +6041,7 @@
               MulDiv(DsgDataModule.DesignSize.x, Screen.PixelsPerInch, DsgDataModule.DesignPPI),
               MulDiv(DsgDataModule.DesignSize.y, Screen.PixelsPerInch, DsgDataModule.DesignPPI));
             DsgDataModule.DesignPPI := Screen.PixelsPerInch;
+            AnUnitInfo.Modified := True;
sourcefilemanager-1.patch (1,378 bytes)   

Juha Manninen

2019-04-05 11:12

developer   ~0115239

I uploaded the patch made by Ondrej from the related issue here.
I guess it is meant to fix this issue instead of the AnchorDocking issue.
The patch however has a problem: The IDE asks to save a project always even nothing was changed. It must be improved somehow.


2019-07-28 14:48

developer   ~0117458

Last edited: 2019-07-28 14:49

View 2 revisions

I cannot reproduce this issue with Laz trunk/fpc 3.0.4 (Win10).

The attached project ("") is set up for LCL scaling (Project options: "LCL scaling" checked, "Use manifest resource", "DPI awareness" = "on (True)". it was written with Laz trunk/fpc3.0.4 on Win10 at 96 ppi. When I copy the project to a VM with Win 7 at 144ppi and open the project there, everything is scaled correctly (except for some minor differences) without anything else to do. Also, running the project on the higher-dpi system shows the scaled form.

In my opinion it is not necessary to mark the lfm as "modified" when it is only opened on the system having different ppi. The LCL scaling machinery detects the difference in the DesignTimePPI of the lfm and the current machine and rescales dimension accordingly so that the form is displayed correctly. When the project is saved and the lfm is re-written the file gets the new PPI and the new dimension values so that a rescaling process will not occur again when the project is opened on the same machine later. Of course, when the lfm is not written because no lfm-relevant changes were made, the file will still contain the old ppi and old dimensions so that next opening of the form will activate LCL scaling again.

When the application needs the rescaled coordinates/dimensions it must not query them too early, LCL scaling must have completed its job and the application must have finished reacting on the related changes. I noticed that OnCreate is often too early. OnShow is better.


2019-07-28 14:49

developer (2,203 bytes)

Ondrej Pokorny

2019-07-28 15:01

developer   ~0117459

You are missing the point. You don't see the problem because in run-time the form is scaled from 96 PPI to 144 PPI - so you see no difference. The point is the form should be saved with 144 PPI when opened on a 144 PPI system.

The problem is perfectly reproducible - you just did not follow the steps.


2019-07-28 16:39

developer   ~0117463

Last edited: 2019-07-28 17:59

View 8 revisions

I don't understand. These are my steps:

- The project "" was created at 96 ppi. Open unit1.lfm in an editor -> no DesignTimePPI property, i.e. is at default, 96 ppi, Width = 742, Height = 240.
- Copied project to VM with Windows at 144 ppi (150%).
- Open form in Laz at high-res system: Form appears to be larger, Objectinspector shows: DesignTimePPI = 144, form is scaled to Width = 1113 (=742*1.5) and Height = 360 (240*1.5); using a screen ruler I can measure approximately these dimensions.
- Compile and run -> form appears in its scaled size on the monitor --> correct.
- Before compilation the project in principle is saved, but because nothing was changed the lfm file is left unmodified: Open the lfm in an editor in the high-res system: still no DesignTimePPI value (i.e. 96 ppi), Width = 742, Height = 240.
- This means LCL scaling correctly updates old dimensions and ppi values when the form is opened on a system with a different ppi value than where it was created.
- Move the form in the IDE (of the high-dpi system) to a different position. Save project.
- Open the lfm in an editor. Now DesignTimePPI is 144, Width = 1113, Height = 360. --> correct.

--> The values in the lfm always reflect the state in which the file was last modified. That's how it should be. LCL scaling takes care of the rest.

Which one of the "Steps to reproduce" did I miss?

Maybe I should add that the option "Force DPI scaling at design-time" has its default value (true). The OP, however, seems to use Laz 1.8 where this property did not yet exist.

No. I restored the original "low-dpi" project on the high-dpi system. Installed Laz 1.8.0 on the high-dpi system. Opened the original project there --> same result: the form is scaled at design time. Only after I open the lfm file in an editor and add the line "Scaled = false" I get the unscaled form after opening the project in both Laz 1.8.0 and Laz-trunk (the "Force DPI scaling at design-time" setting does not matter in the latter case.

ok, I see my sentence "I cannot reproduce this issue .." was incorrect. Of course, i can reproduce DesignTimePPI being different between lfm and object inspector. I think I've seen too many similar scaling issues recently and probably had the related anchordocking issue in mind.

But why is this difference a problem when the IDE takes care of the necessary scaling steps? It's like specifiying a distance in meters and in miles - it is always the same distance, just different numbers; and the units for the numbers are given in the lfm file, too. So, what is the problem?

Juha Manninen

2019-10-06 12:48

developer   ~0118372

Detaching myself.

Issue History

Date Modified Username Field Change
2019-03-15 11:20 PeterX New Issue
2019-03-15 12:26 Pascal Riekenberg Note Added: 0114834
2019-03-15 12:54 Juha Manninen Relationship added related to 0034841
2019-04-05 10:59 Juha Manninen Assigned To => Juha Manninen
2019-04-05 10:59 Juha Manninen Status new => assigned
2019-04-05 11:06 Juha Manninen File Added: sourcefilemanager-1.patch
2019-04-05 11:12 Juha Manninen Note Added: 0115239
2019-07-28 14:48 wp Note Added: 0117458
2019-07-28 14:49 wp File Added:
2019-07-28 14:49 wp Note Edited: 0117458 View Revisions
2019-07-28 15:01 Ondrej Pokorny Note Added: 0117459
2019-07-28 16:39 wp Note Added: 0117463
2019-07-28 16:46 wp Note Edited: 0117463 View Revisions
2019-07-28 16:53 wp Note Edited: 0117463 View Revisions
2019-07-28 16:59 wp Note Edited: 0117463 View Revisions
2019-07-28 17:15 wp Note Edited: 0117463 View Revisions
2019-07-28 17:16 wp Note Edited: 0117463 View Revisions
2019-07-28 17:28 wp Note Edited: 0117463 View Revisions
2019-07-28 17:59 wp Note Edited: 0117463 View Revisions
2019-10-06 12:48 Juha Manninen Assigned To Juha Manninen =>
2019-10-06 12:48 Juha Manninen Status assigned => new
2019-10-06 12:48 Juha Manninen LazTarget => -
2019-10-06 12:48 Juha Manninen Note Added: 0118372