Hi every one,
I am a quite long Lazarus user now
and I must say I really enjoy the IDE and Pascal language productivity. Lazarus and FPC are getting better and better with any new version. I would like to thank @Martin for his amazing job on fpDebug, specially on the upcoming 2.4 version.
I am now facing a new challenge as I need to move some of my applications to HighDPI.
I am quite sure many of us will need to go that way in the months or years to come because 96Dpi screens will become very hard to find and most users will (or already) have different screen size and dpi.
Lazarus / LCL does a decent job when you use the anchoring system with simple forms and only 96DPI design time but many problems arise when you start embedding frames at runtime or using third party components.
I already opened a ticket in the bugtracker for this :
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39837 as a starting point but it didn’t get much traction yet.
Anyway, here are some feedback (most of the points are already on the wiki
https://wiki.freepascal.org/High_DPI) to help with High DPI:
1. Design your forms or frames at 96Dpi only. You will get unexcepted results otherwise even if the DesignTimeDpi property should handle that.
2. Project options: enable LCL Scaling (this will set Application.Scaled to True)
3. Project options: for windows, if you don’t want to spend too much time checking your forms or frames, simply use ‘DPI Awareness’ = True. Your application will appear quite blurry on High Dpi screens but you should not have many problems (tested on windows 8.1 and up). Per monitor/V2 will bring you sharp display but you really will need to spend time to check every forms/frames.
4. Check TForm.Scaled and TFrame.Scaled property is True (default)
5. Always use the anchoring system and really specify the control you want to use as an anchor (no blank even when you want to anchor to the form or the frame itself).
6. Avoid anchoring a control to left and right if possible. The right or bottom anchors are not always properly applied, may be because the resizing occurs before the form/frame resizing? In that case you often have to adjust your layout at runtime.
7. Avoid align:=alxxxx and use the anchoring system instead. This is especially true for frames.
8. Set ParentFont := True as much as possible, especially for frames
9. I now use TOMultiPanel from Ondrej Pokorny instead of Splitters with far better results for HighDpi. No advertising here but AFAIK Ondrej also worked on the HighDpi part of LCL.
Please correct me if you experienced otherwise.
There are several things that I really miss when working on the same project on different computers with different screens Dpi:
An option to lock *.lfm files in a project and prevent them to be saved:When working on HighDPI display, the lfm files are flagged ‘changed‘ as soon as you move a form on the screen so it can be very tricky when you only want to work on your application source code and not the layouts. These is especially annoying because your lfm are saved with a new DesignTimeDpi and you usually don’t want that to happen.
An event added to TCustomForm.WMDPIChanged(var Msg: TLMessage); like :If Assigned(FOnDPIChanged)
Then FOnDPIChanged(Self);
It would be useful when you need to load new resources, adjust bounds, font or layouts by code. I guess same can be done via OnResize or OnChangeBounds but you don’t want to load resources every time bounds are changed.
And last, I don’t know if someone is able to use AnchorDocking on HighDPI display but I cannot because scrollbars are missing in the code editors
Recent
