[Lazarus] TFrame improvements

[Martin Frb]

On 29/11/2021 12:31, Ondrej Pokorny via lazarus wrote:
> I didn't study the issue further but to me it looks strange that 
> setting some parameters in CreateParams helps with it. Juha, your 
> commit description "Somehow fixes issue ..." doesn't help to 
> understand your change either.

"Setting" is actually "removing" => removing "WS_Child" allows the frame 
to be created as a top-level window.

So before this, while the frame was created (and did not have a parent), 
that "buggy component" accessed the canvas. => Handle creation failed.
=> Now handle creation works. (note, that the handle is probably never 
"shown" , set to visible=true)

So that is why the patch "works"


Actually, come to think of it, maybe it be different.
=> it just allows a temporary handle (that will be thrown away without 
ever being visible), only to support buggy code, and that should not 
happen....

Yet:
- Afaik/IIRC if read from stream as part of a form in runtime => the 
parent is already set (the form).
   So at runtime such buggy code would work
- If indeed so, the IDE would have to make sure, that the "designer" is 
already set as a parent, when reading the stream.

Well, that is:
I guess, when the frame is show stand alone in the IDE it has the 
designer as parent (not verified, but must have something, as it can be 
shown -- and until now it could not be shown as top level window).

Then again, setting the designer as parent for reading the stream, may 
not be trivial at all.
In which case we may go with the "dummy handle" but for designtime only.