[ SOLVED ] Strange Error using Frame

[linuxfan]

As promised, I took the not-working frametf.lfm file, added "ParentFont = false" in the two panels, deleted the DesignTimePPI, and now the IDE behaves normally.

Target reached.

A few thoughts:

- Probably there is a bug in the IDE, somewhere. May also be that the message "no parent window" is a catch-all that shows even when the error is different.

- I would like to debug/investigate the IDE and find the bug, but I am afraid to lose too much time and implement a not-so-right solution

About the PPI. I don't notice, at the moment, anything wrong, but that does not count. From a certain perspective, it is *wrong* to rely on PPIs (or DPIs) when designing a form and, maybe, it is wrong that a form designer relies on that. But I am not sure. I think it is best, always, to pack/align/anchor widgets and let the user choose dimensions for fonts, panels and so on - but this is often more work (it is so faster to click and place items in a form...).

But in this particular case, it is more important to be able to work on my project using my three computers than to have correct sizes in the form because sizes are never "correct", they are only in a particular situation. In fact, my project will have preferences for that too; more: I am implementing mouse wheel to zoom (lately my eyes are loosing efficiency...); I noticed that good programs use the wheel as much as possible, and let the user customize the GUI. I also noticed that poorly written programs or OSes tend to limit the user, because they supposedly "know what is right", and I hate them.

[superc]

As promised, I took the not-working frametf.lfm file, added "ParentFont = false" in the two panels, deleted the DesignTimePPI, and now the IDE behaves normally.

Target reached.

A few thoughts:

- Probably there is a bug in the IDE, somewhere. May also be that the message "no parent window" is a catch-all that shows even when the error is different.

- I would like to debug/investigate the IDE and find the bug, but I am afraid to lose too much time and implement a not-so-right solution

About the PPI. I don't notice, at the moment, anything wrong, but that does not count. From a certain perspective, it is *wrong* to rely on PPIs (or DPIs) when designing a form and, maybe, it is wrong that a form designer relies on that. But I am not sure. I think it is best, always, to pack/align/anchor widgets and let the user choose dimensions for fonts, panels and so on - but this is often more work (it is so faster to click and place items in a form...).

But in this particular case, it is more important to be able to work on my project using my three computers than to have correct sizes in the form because sizes are never "correct", they are only in a particular situation. In fact, my project will have preferences for that too; more: I am implementing mouse wheel to zoom (lately my eyes are loosing efficiency...); I noticed that good programs use the wheel as much as possible, and let the user customize the GUI. I also noticed that poorly written programs or OSes tend to limit the user, because they supposedly "know what is right", and I hate them.

first of all, thank you very much your support is greatly appreciated;
now I'm try to add 'ParentFont = false' to all 21 tpanel used; but what's DesignTimePPI?

[MarkMLl]

- I would like to debug/investigate the IDE and find the bug, but I am afraid to lose too much time and implement a not-so-right solution

My experience is that debugging the IDE isn't too bad: simply compile and run a new instance inside an existing IDE (I can't say whether IDE Options ... Lazarus instances has to be explicitly set to "Always start a new instance", since that's what I always use).

MarkMLl

[linuxfan]

@superc: DesignTimePPI is, for what I understand, a relatively new feature of the IDE which stores the PPI (pixels per inch?) used when creating a form. So if you have a very "resoluted" screen and you design a very big form, when the application runs on a lower resolution the application can scale the form and its contents to mantain the overall appearance. Otherwise, you would end up with big forms with much space between controls. Or the contrary. Probably also the Scaled property plays a role. I say "for what I understand" because I noticed that DesignTimePPI by stumbling upon it, in one of the numerous occasions I transfer Lazarus sources from a PC to another.

@MarkMLI: the problem, for me, is not about debugging the IDE, but about understanding the mechanisms and then find the correct solution. I find LCL and, in general, the Freepascal runtime beatiful but complicated and full of obscure techniques. Nothing impossible to understand, but time is needed. Perhaps, when I will retire, I will find the time and the pleasure to contribute to Lazarus and Debian... still a few years must pass!

[wp]

but about understanding the mechanisms and then find the correct solution.

Understanding is fine, but there is not need for you to find a solution because the issue has been fixed in "SHA-1: f5da5df4fb2e16e3620872aac6762f750021b80b LCL:  High-DPI: fix inplace frames. Issue #36370 / git-svn-id: trunk@62507" (Jan 7, 2020 by Ondrej). This is the first revision in which this issue does not appear any more. Possibily because of the complexity of this fix it did not make it into the v2.0.12 release. You should check out the 2.2RC1 where the issue is solved.

[superc]

but about understanding the mechanisms and then find the correct solution.

Understanding is fine, but there is not need for you to find a solution because the issue has been fixed in "SHA-1: f5da5df4fb2e16e3620872aac6762f750021b80b LCL:  High-DPI: fix inplace frames. Issue #36370 / git-svn-id: trunk@62507" (Jan 7, 2020 by Ondrej). This is the first revision in which this issue does not appear any more. Possibily because of the complexity of this fix it did not make it into the v2.0.12 release. You should check out the 2.2RC1 where the issue is solved.

I confirm that in version 2.2RC2 and 2.3 (which I tested this morning) the issue is solved.