View Issue Details

IDProjectCategoryView StatusLast Update
0038702PackagesPackagespublic2021-04-08 00:07
ReporterMartok Assigned ToMichl  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
OSWin8.1 
Fixed in Version2.1 (SVN) 
Summary0038702: dockedformeditor: border at bottom-right gets added to form dimensions
DescriptionThe dockedformeditor has some strange "padding" of 4px at the bottom and right side of forms.

Attached screenshot shows a 440x280px TShape at 0,0 on a 440x280px TForm. Note that there is a "gap" between the TShape's outline and the resize grips.

This padding is not just cosmetic, resizing the form uses this padded size as the start point, so the Form grows by 4px on every resize attempt.
TagsNo tags attached.
Fixed in Revision64933, 64943
LazTarget-
WidgetsetWin32/Win64
Attached Files

Relationships

related to 0038701 confirmedMichl dockedformeditor: dimensions of form with menu are wrong 

Activities

Martok

2021-04-04 04:30

reporter  

dfe_border.png (2,045 bytes)   
dfe_border.png (2,045 bytes)   

Michl

2021-04-04 12:14

developer   ~0130073

All widgetsets, I can test here, don't show this issue. I don't have a Win8.1 here for testing. But maybe it is not the OS but something else.

Can you please add a minimal project, that shows this issue.

Martok

2021-04-04 21:36

reporter   ~0130087

Last edited: 2021-04-05 00:14

View 3 revisions

Minimal test is just "drop any sizeable on a form, set to Align=alClient, observe edges don't fit to TResizeFrame."

If you can't reproduce then it can well be the window manager, I'll see if I can figure this out. Seems like an lower entry level than the other one :)

Edit: looks like a DPI scaling problem. Re-saving dockedresizeframe.lfm with my DesignTimePPI=120 makes the problem go away locally. Changing OS setting now to see what happens.

Edit2: yep, DPI. Setting Windows to 100% (96DPI) fixes the problem with unmodified dockedformeditor.

Michl

2021-04-05 00:04

developer   ~0130092

> Edit: looks like a DPI scaling problem. Re-saving dockedresizeframe.lfm with my DesignTimePPI=120
> makes the problem go away locally. Changing OS setting now to see what happens.

Thank you for pointing this out! Never change the DPI of dockedresizeframe, it should always be 96dpi as documented in header!!! Otherwise the scaling magic get lost.

Can you revert the changes and try a clean build and check if it works?

Martok

2021-04-05 00:24

reporter   ~0130093

Last edited: 2021-04-05 00:24

View 2 revisions

Ah, didn't see your message before editing above.
Seems to be exactly the other way around: ResizeFrame must be saved in the same DPI as the system for it to work. Something important is not scaled at all there.

System=96, LFM="unset" : correct
System=96, LFM=120: panel is 4px smaller than DesignForm
System=120, LFM="unset": panel is 4px larger than DesignForm
System=120, LFM=120: correct
(unset being the file as it exists in SVN)

How does one "not change" DesignTimePPI? The IDE just does that... Originally I hadn't even opened the form editor, just opened the .pas to enable the DEBUGDOCKEDFORMEDITOR define. Saving that changed the LFM as well.

Michl

2021-04-05 00:42

developer   ~0130095

> Seems to be exactly the other way around

OK thank you for the hint. This was working for a while, maybe I have broken it somehow. I'll check this.

> How does one "not change" DesignTimePPI? The IDE just does that... Originally I hadn't even
> opened the form editor, just opened the .pas to enable the DEBUGDOCKEDFORMEDITOR
> define. Saving that changed the LFM as well.

You can build the IDE with option -dDEBUGDOCKEDFORMEDITOR or set -dDEBUGDOCKEDFORMEDITOR in Package Custom Options.

Martok

2021-04-05 01:46

reporter   ~0130098

Current suspect: the scaling of SizerGripSize vs. the scaling of the actual sizer grip panels (maybe in TResizeFrame.AdjustPanelResizer).
The difference between 2*8 and 2*8*(120/96) is exactly the 4px.

> You can build the IDE with option -dDEBUGDOCKEDFORMEDITOR or set -dDEBUGDOCKEDFORMEDITOR in Package Custom Options.
Right, I should have known this. Really should do something against that old Delphi habit of uncommenting switches in headers...

Martok

2021-04-05 22:06

reporter   ~0130118

> Current suspect: the scaling of SizerGripSize
That's it. The sizer frame does not get scaled at all, the grips remain at 8px. So when FSizerGripSize is initialized with scaling, it ends up too big.

Patch that takes whatever the real size is attached... needs testing on other widgetsets, but at least here it works for the corret LFM and even after I "accidentally" save the LFM with a DesignTimePPI set.

Michl

2021-04-05 23:18

developer   ~0130121

Thank you, but dont investigate time in this issue. I tested it here with multiple different situations. I rewrite this part and I'll create all dynamically to prevent future problems. It will take a little bit.

Martok

2021-04-06 00:12

reporter   ~0130123

Alright, just trying to be helpful since I'm happy you picked up work on this package :)
Let me know when something needs testing.

Michl

2021-04-06 23:37

developer   ~0130145

Thank you for your offered support! Best thing is to work with this package and open a separate bug report for each issue, so things can be improved and I don't miss it. Simple as you already have done.

This problem should be fixed in revision 64933. Please test an close if OK.

Martok

2021-04-07 22:04

reporter   ~0130163

Last edited: 2021-04-07 22:12

View 2 revisions

Resizing, Borders etc works great now!

One final thing though ;-)
The default TWinControl is transparent so the parent's background color is painted regardless of the explicitly set clBtnFace. Adding FFormClient.ControlStyle:= FFormClient.ControlStyle + [csOpaque]; in TResizeContainer.Create should be correct for all widgetsets.

Michl

2021-04-07 23:09

developer   ~0130167

Thank you for the hint. I haven't seen it here on Win7 classic theme, Aero theme shows the problem. Commited in revision 64943.

Martok

2021-04-08 00:07

reporter   ~0130168

I also wouldn't have seen it on my Win10 with its stupid white-in-white desert design...

All good now, thanks!

Issue History

Date Modified Username Field Change
2021-04-04 04:30 Martok New Issue
2021-04-04 04:30 Martok File Added: dfe_border.png
2021-04-04 12:14 Michl Assigned To => Michl
2021-04-04 12:14 Michl Status new => feedback
2021-04-04 12:14 Michl LazTarget => -
2021-04-04 12:14 Michl Note Added: 0130073
2021-04-04 12:24 Michl Relationship added related to 0038701
2021-04-04 21:36 Martok Note Added: 0130087
2021-04-04 21:36 Martok Status feedback => assigned
2021-04-04 23:00 Martok Note Edited: 0130087 View Revisions
2021-04-05 00:04 Michl Note Added: 0130092
2021-04-05 00:05 Michl Status assigned => feedback
2021-04-05 00:14 Martok Note Edited: 0130087 View Revisions
2021-04-05 00:24 Martok Note Added: 0130093
2021-04-05 00:24 Martok Status feedback => assigned
2021-04-05 00:24 Martok Note Edited: 0130093 View Revisions
2021-04-05 00:42 Michl Note Added: 0130095
2021-04-05 01:46 Martok Note Added: 0130098
2021-04-05 22:06 Martok Note Added: 0130118
2021-04-05 23:18 Michl Note Added: 0130121
2021-04-06 00:12 Martok Note Added: 0130123
2021-04-06 23:37 Michl Status assigned => resolved
2021-04-06 23:37 Michl Resolution open => fixed
2021-04-06 23:37 Michl Fixed in Version => 2.1 (SVN)
2021-04-06 23:37 Michl Fixed in Revision => 64933
2021-04-06 23:37 Michl Widgetset Win32/Win64 => Win32/Win64
2021-04-06 23:37 Michl Note Added: 0130145
2021-04-07 22:04 Martok Status resolved => assigned
2021-04-07 22:04 Martok Resolution fixed => open
2021-04-07 22:04 Martok Note Added: 0130163
2021-04-07 22:12 Martok Note Edited: 0130163 View Revisions
2021-04-07 23:09 Michl Status assigned => resolved
2021-04-07 23:09 Michl Resolution open => fixed
2021-04-07 23:09 Michl Fixed in Revision 64933 => 64933, 64943
2021-04-07 23:09 Michl Widgetset Win32/Win64 => Win32/Win64
2021-04-07 23:09 Michl Note Added: 0130167
2021-04-08 00:07 Martok Note Added: 0130168
2021-04-08 00:07 Martok Status resolved => closed