View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0034841 | Lazarus | IDE | public | 2019-01-09 13:07 | 2021-03-15 11:33 |
Reporter | Pascal Riekenberg | Assigned To | Pascal Riekenberg | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Platform | i386 | OS | Windows 10 x64 | ||
Product Version | 2.1 (SVN) | ||||
Summary | 0034841: AnchorDocking: Loading layouts does not consider HighDPI scaling | ||||
Description | I've designed some forms on a machine with 144 PPI. If i open the project on a machine with 96 PPI the object inspector shows 96 PPI but the lfm file still contains 144 and the lfm is not marked as modified. So to bring the corrct PPI to the lfm file i have to modify the form myself. The lfm file should be marked as modified when DesignTimePPI changes, so it gets written to file on next compile. This error has annoying effect with loading layouts in anchordocking. | ||||
Tags | No tags attached. | ||||
Fixed in Revision | |||||
LazTarget | - | ||||
Widgetset | Win32/Win64 | ||||
Attached Files |
|
|
Form should not be modified if you only open it? What annoying behavior exactly do you get? |
|
>Form should not be modified if you only open it? It will not be modified if i open it, though the DesignTimePPI is changed and probably all PPI related properties. If i move the form it gets modified and the error does not appear. >What annoying behavior exactly do you get? When loading an anchordocking layout the docked forms do not get reconstructed like they have been on last save on the same machine. So the root cause may be that the executable has the high ppi values inside now. If i manually modify all forms (just move) and generate an executable, the same layout gets loaded as expected again. I'll try to build a miniide example setup. Were do you need the bug to happen? 96 or 144 PPI? |
|
It does not matter for me. Let it be 96 PPI. |
|
> When loading an anchordocking layout the docked forms do not get reconstructed like they have been on last save on the same machine. Are you sure that the AnchorDocking package implements LCL scaling correctly? It took me some time to understand it, and still I am faced sometimes with situtations when something does not work as expected. When AnchorDocking does not scale correctly this is a matter of this package, not of the entire architecture. Only somebody has to take the time to understand it and fix the issue. I strongly advise against changing anything in the basic LCL scaling mechanism, I am absolutely sure that it will break everything. |
|
I don't remember: does AnchorDocking even support High-DPI? I think I did not work on it. The issue is simple: the IDE doesn't set the modified flag for form's LFM when it loads a form on a different DPI. This can be fixed rather easily. There aren't needed any changes in LCL. The "annoying issue" is easy to explain: if the DPI values differ, you see the bug in AnchorDocking. When you resave, your DPI values get equal and you don't see the anchor docking bug. So there are 2 independent bugs: 1.) IDE that doesn't set the modified flag. 2.) Bug in AnchorDocking - that should be reported separately. |
|
Possible patch attached (sourcefilemanager-1.patch). I had to remove the "Project1.ClearModifieds(true);" line that cleared all modified flags after the project was loaded. I don't know, maybe it could have some side-effects. |
|
>Are you sure that the AnchorDocking package implements LCL scaling correctly? No it doesn't, in fact it shouldn't make any difference which DesignTimePPI is used as long as the DPI dependent properties correlate to the DesignTimePPI. >So there are 2 independent bugs: >1.) IDE that doesn't set the modified flag. Right, but shouldn't make any difference as this only affects opened forms. Others are still in the "old" DesignTimePPI and this leads to the bug in AnchorDocking. >2.) Bug in AnchorDocking - that should be reported separately. I think this is the place to report as 1) isn't realy a bug. So please change title to: AnchorDocking: Loding layouts does not consider HighDPI scaling |
|
I moved the Ondrej's patch from here to the related issue. The patch is not about AnchorDocking. |
|
> I'll try to build a miniide example setup. Were do you need the bug to happen? 96 or 144 PPI? Please, do so. No matter whether the bug appears in scaling up or in scaling down, you only must tell which way. And give precise step-by-step instructions what to do to reproduce the error. |
|
This is no issue. The problem was that the layout was loaded during form constructor (before LCL scaling) instead of in FormCreate event (when LCL scaling is done already) |
Date Modified | Username | Field | Change |
---|---|---|---|
2019-01-09 13:07 | Pascal Riekenberg | New Issue | |
2019-01-10 23:07 | Maxim Ganetsky | LazTarget | => - |
2019-01-10 23:07 | Maxim Ganetsky | Note Added: 0113313 | |
2019-01-10 23:07 | Maxim Ganetsky | Status | new => feedback |
2019-01-10 23:07 | Maxim Ganetsky | Summary | DesignTimePPI is not updated in LFM when load machine with other PPI => DesignTimePPI is not updated in LFM when loading on machine with other PPI |
2019-01-11 06:15 | Pascal Riekenberg | Note Added: 0113320 | |
2019-01-11 06:15 | Pascal Riekenberg | Status | feedback => new |
2019-01-11 13:11 | Maxim Ganetsky | Note Added: 0113325 | |
2019-01-11 15:37 | wp | Note Added: 0113328 | |
2019-01-11 21:30 | Ondrej Pokorny | Note Added: 0113337 | |
2019-01-11 21:31 | Ondrej Pokorny | Note Edited: 0113337 | View Revisions |
2019-01-11 21:31 | Ondrej Pokorny | Note Edited: 0113337 | View Revisions |
2019-01-11 21:47 | Ondrej Pokorny | File Added: sourcefilemanager-1.patch | |
2019-01-11 21:50 | Ondrej Pokorny | Note Added: 0113338 | |
2019-01-12 06:07 | Pascal Riekenberg | Note Added: 0113346 | |
2019-01-12 06:09 | Pascal Riekenberg | Note Edited: 0113346 | View Revisions |
2019-01-13 23:24 | Maxim Ganetsky | Summary | DesignTimePPI is not updated in LFM when loading on machine with other PPI => AnchorDocking: Loding layouts does not consider HighDPI scaling |
2019-01-13 23:26 | Maxim Ganetsky | Summary | AnchorDocking: Loding layouts does not consider HighDPI scaling => AnchorDocking: Loading layouts does not consider HighDPI scaling |
2019-03-15 12:54 | Juha Manninen | Relationship added | related to 0035231 |
2019-04-05 11:13 | Juha Manninen | File Deleted: sourcefilemanager-1.patch | |
2019-04-05 11:14 | Juha Manninen | Note Added: 0115240 | |
2019-07-28 17:20 | wp | Note Added: 0117464 | |
2021-03-02 21:22 | Michl | Relationship added | related to 0036718 |
2021-03-15 11:32 | Pascal Riekenberg | Assigned To | => Pascal Riekenberg |
2021-03-15 11:32 | Pascal Riekenberg | Status | new => resolved |
2021-03-15 11:32 | Pascal Riekenberg | Resolution | open => no change required |
2021-03-15 11:32 | Pascal Riekenberg | Widgetset | Win32/Win64 => Win32/Win64 |
2021-03-15 11:32 | Pascal Riekenberg | Note Added: 0129682 | |
2021-03-15 11:33 | Pascal Riekenberg | Status | resolved => closed |