[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