[Lazarus] TFrame improvements
Michael Van Canneyt
michael at freepascal.org
Mon Nov 29 11:36:37 CET 2021
On Mon, 29 Nov 2021, Martin Frb via lazarus wrote:
> On 29/11/2021 10:52, Juha Manninen via lazarus wrote:
>> Please everybody test issue:
>> https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/25124
>> Some components caused an error when placed on a Frame. Now it
>> apparently works.
>> Can somebody please explain why it works. (See my comment there).
>>
>
> From reading the issue, and a peak at the code:
>
> - When the frame is read from stream, the property is triggered, as it
> should (and as on a Form.
> - The property accesses "canvas" => that triggers asking for a handle
> (which is created based on CreateParams)
>
> A form does not need a parent (it can have one, if it is embedded).
> Therefore CreateParam for TForm checks this and removes flags such as
> WS_CHILD (not sure if WS_TABSTOP would cause an issue, but it makes no
> sense...)
>
> A frame, at least at design time, can display without parent too. (I
> guess: it acts as if it is a TForm in that case).
> => So for that IMHO your patch is correct (for design time).
>
> Yet a TFrame at runtime IMHO should always have a parent.
> No idea, if there is other code, that relies on that....
> So maybe your patch should be extended, to only do that, if the control
> is in "designtime" state?
> Though, not sure if it is worth it. While it would be correct to fail at
> runtime if there is no parent, it would not bring any benefit. If other
> code in TFrame needs the parent, then it will fail in the other code, if
> not then it will work.
> The question is, do we commit to it may work, and then maybe have to fix
> more later? Otherwise it may want to even throw an exception, if it does
> not have a parent at runtime?
I often create a frame in code (so no parent) which is then placed on a form.
Will this scenario still work ?
Michael.
More information about the lazarus
mailing list