On 29.11.2021 17:18, Juha Manninen via lazarus wrote:
On Mon, Nov 29, 2021 at 1:32 PM Ondrej Pokorny via lazarus
<lazarus@lists.lazarus-ide.org <mailto:lazarus@lists.lazarus-ide.org>>
wrote:
There are many scenarios when the Canvas cannot be accessed and it
is a
common mistake to access it when not allowed.
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.
The commit message is not perfect but the committed code is, now that
I fully understand the issue.
CreateParams for Frame now follows the same logic as CreateParams for
Form.
Frame is not a form.
It allows a Frame to stand without a parent in the designer or even at
runtime in some hypothetical situation(?).
We definitely should't do anything with the parameters at runtime and
don't allow frames to be shown as forms by default. What buttons
(min/max/close/...) should be shown, what border style wtc etc? If the
programmer wants to show his frame as a standalone form, he can override
CreateParams() on his own.
Using Canvas outside Paint may not be recommended but it can be done
in some widgetsets. The component's duty is to not crash in designer
or anywhere else when it happens.
Well, if the programmer writes his code so that it crashes, what do you
want to do with it?
Yes, we should handle exceptions in the designer. But your code doesn't
improve this.
So I would encourage the component author to rewrite his code.
Rewrite? Ok, then TCustomForm must be rewritten, too. They now follow
the same logic, at least regarding CreateParams().
Rewrite his code = the custom component, not TFrame, not TCustomForm.
It's basically a very bad idea to force create the handle when the
component is loaded (that is what you do when you access the canvas).
Ondrej
--
_______________________________________________
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
