Re: [Lazarus] TFrame improvements

[Ondrej Pokorny via lazarus]

On 30.11.2021 00:27, Juha Manninen via lazarus wrote:
On Mon, Nov 29, 2021 at 11:14 PM Ondrej Pokorny via lazarus 
mailto:lazarus@lists.lazarus-ide.org>> 
wrote:


On 29.11.2021 17:18, Juha Manninen via lazarus wrote:

The commit message is not perfect but the committed code is, now
that I fully understand the issue.


That is nonsense. I reverted your change. The code user code is
just plain wrong and your change in TFrame doesn't change anything
about it.

No, the code is valid although not recommended. Accessing Canvas 
outside Paint works with some widgetsets and then an exception is wrong.


No, Juha, you don't understand the issue at all.

Accessing Canvas outside Paint is OK under all widgetsets if done 
correctly. Whenever you access the canvas for text measuring you have to 
make sure you can do so. There are 2 solutions for it:


1.) Check HandleAllocated and skip the measurements if the handle is not 
allocated. Like here: 
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/6e5e5b67df9d26cd477588a27029c8007d08add2


- or -

2.) If you really have to do the measurements and return something, 
create an extra handle for the canvas like in TCustomLabel.CalculateSize.


---

The LCL's function is not to force creating the canvas when it cannot be 
naturally created with manipulating itself like you did.


Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] New Synthwave Demo

[Anthony Walter via lazarus]

Hi guys,

I just wanted to let you know I completed writing my final demo to be
included in my soon to be released vector graphics and custom UI toolkit.

On this page  is the
video and source code of the project.
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Juha Manninen via lazarus]

On Mon, Nov 29, 2021 at 11:14 PM Ondrej Pokorny via lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On 29.11.2021 17:18, Juha Manninen via lazarus wrote:
>
> The commit message is not perfect but the committed code is, now that I
> fully understand the issue.
>
> That is nonsense. I reverted your change. The code user code is just plain
> wrong and your change in TFrame doesn't change anything about it.
>
No, the code is valid although not recommended. Accessing Canvas outside
Paint works with some widgetsets and then an exception is wrong.

Juha
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Ondrej Pokorny via lazarus]

On 29.11.2021 17:18, Juha Manninen via lazarus wrote:
On Mon, Nov 29, 2021 at 1:32 PM Ondrej Pokorny via lazarus 
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.


That is nonsense. I reverted your change. The code user code is just 
plain wrong and your change in TFrame doesn't change anything about it.


Try e.g. :

procedure TForm1.Button1Click(Sender: TObject);
var
  grid: TNewGrid;
begin
  grid := TNewGrid.Create(Self);
  grid.MyProperty := 1; // exception
end;

Btw. Delphi behaves the same.

Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Martin Frb via lazarus]

On 29/11/2021 21:20, Ondrej Pokorny via lazarus wrote:


Check TCustomLabel.CalculateSize in lcl\include\customlabel.inc for 
the solution how to solve this problem correctly in the component's 
code without any modifications needed in T(Custom)Form or T(Custom)Frame.


There, the GetDC(0) is used for Canvas.Handle, so that the label's 
parent's handle doesn't need to be created.


That raises another question: Why does it need that before/unless it is 
visible?


Does autosize run, for non-visible components?
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Ondrej Pokorny via lazarus]

On 29.11.2021 21:09, Ondrej Pokorny via lazarus wrote:


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).


Check TCustomLabel.CalculateSize in lcl\include\customlabel.inc for the 
solution how to solve this problem correctly in the component's code 
without any modifications needed in T(Custom)Form or T(Custom)Frame.


There, the GetDC(0) is used for Canvas.Handle, so that the label's 
parent's handle doesn't need to be created.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Ondrej Pokorny via lazarus]

On 29.11.2021 17:47, Martin Frb via lazarus wrote:

On 29/11/2021 17:18, Juha Manninen via lazarus wrote:


It allows a Frame to stand without a parent in the designer or even 
at runtime in some hypothetical situation(?).
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.




I suspect in the Designer it does not stand alone => The designer is 
the parent. But I have not checked.


Unless you have installed the docked designer package (I don't know in 
what shape it is now, AFAIR Michl has done some improvements), the 
designer form is standalone and the frame as well (=they don't have a 
parent).


I assume the IDE designer sets the needed window parameters for the 
frame at some place between loading and showing the frame. But I haven't 
checked now and it's been a while when I fiddled with the designer code 
the last time.


Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Ondrej Pokorny via lazarus]

On 29.11.2021 17:18, Juha Manninen via lazarus wrote:
On Mon, Nov 29, 2021 at 1:32 PM Ondrej Pokorny via lazarus 
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

Re: [Lazarus] TFrame improvements

[Juha Manninen via lazarus]

On Mon, Nov 29, 2021 at 6:47 PM Martin Frb via lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> I suspect in the Designer it does not stand alone => The designer is the
> parent. But I have not checked.
>

No, it has no parent. That is why it crashed.
This is with the default IDE with floating windows. With the docked IDE it
does have a parent.


If it does not, then we have a new problem.
> We now provide a canvas, and let the user believe they painted on it. But
> its invisible. And if in order to make it visible, a parent is required,
> then that means a new Handle.
> So then we throw away the users work. (and the user will forever wonder
> way his output is not drawn)
>

The same potential problem applies to TForm. They both behave equally well
now in the designer.

Juha
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Application.QueueAsyncCall and "conversion between ordinals and pointers is not portable"

[Luca Olivetti via lazarus]

El 29/11/21 a les 17:54, Mattias Gaertner via lazarus ha escrit:

On Fri, 26 Nov 2021 13:15:07 +0100
Luca Olivetti via lazarus  wrote:


Hello,

Application.QueueAsyncCall is defined as

procedure Application.QueueAsyncCall(const AMethod:TDataEvent; Data:
PtrInt);

When I want to pass a string or a big structure as "Data", I create a
pointer and use that, casting it as PtrInt, then I use and free it in
the Async Method., e.g.

procedure TServerThread.Log(const msg:string);
var
s: PString;
begin
new(s);
s^:=msg;
Application.QueueAsyncCall(@MainForm.LogServer, ptrint(s));
end;

procedure TMainForm.LogServer(data: ptrint);
var s:PString;
begin
ptruint(s):=data; //ptrint here gives a warning "use an unsigned
type" LogMemo.Lines.Add(s^);
Dispose(s);
end;


But that gives a hint "conversion between ordinals and pointers is
not portable". The suggestion I found is to use {%H-} to silence that
hint (which I did), but is there a better way?

Why Data is defined as PtrInt and not pointer?


Sometimes you need an integer, sometimes a pointer, and afair at the
time when it was added the compiler did not warn typecasting PtrInt to
Pointer.


True. I checked and now it even gives an hint for an integer typecasted 
to a pointer, so defining it as a pointer would not solve the problem if 
you need to pass a bare integer as data :-(


Bye
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Application.QueueAsyncCall and "conversion between ordinals and pointers is not portable"

[Mattias Gaertner via lazarus]

On Fri, 26 Nov 2021 13:15:07 +0100
Luca Olivetti via lazarus  wrote:

> Hello,
> 
> Application.QueueAsyncCall is defined as
> 
> procedure Application.QueueAsyncCall(const AMethod:TDataEvent; Data: 
> PtrInt);
> 
> When I want to pass a string or a big structure as "Data", I create a 
> pointer and use that, casting it as PtrInt, then I use and free it in 
> the Async Method., e.g.
> 
> procedure TServerThread.Log(const msg:string);
> var
>s: PString;
> begin
>new(s);
>s^:=msg;
>Application.QueueAsyncCall(@MainForm.LogServer, ptrint(s));
> end;
> 
> procedure TMainForm.LogServer(data: ptrint);
> var s:PString;
> begin
>ptruint(s):=data; //ptrint here gives a warning "use an unsigned
> type" LogMemo.Lines.Add(s^);
>Dispose(s);
> end;
> 
> 
> But that gives a hint "conversion between ordinals and pointers is
> not portable". The suggestion I found is to use {%H-} to silence that
> hint (which I did), but is there a better way?
> 
> Why Data is defined as PtrInt and not pointer?

Sometimes you need an integer, sometimes a pointer, and afair at the
time when it was added the compiler did not warn typecasting PtrInt to
Pointer.

Mattias


> 
> Bye

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Martin Frb via lazarus]

On 29/11/2021 17:18, Juha Manninen via lazarus wrote:


It allows a Frame to stand without a parent in the designer or even at 
runtime in some hypothetical situation(?).
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.




I suspect in the Designer it does not stand alone => The designer is the 
parent. But I have not checked.


As for "at runtime" and "stand alone" (which at design time may not be 
possible, if the designer forces itself as parent).

Is that now possible. Has anyone tested?
Just because it can get a handle does not mean it will work if you try 
to make the handle visible.


If it does fine.

If it does not, then we have a new problem.
We now provide a canvas, and let the user believe they painted on it. 
But its invisible. And if in order to make it visible, a parent is 
required, then that means a new Handle.
So then we throw away the users work. (and the user will forever wonder 
way his output is not drawn)


So can a frame be visible shown standalone? And do we want to support 
that. (fix bugs on it, make it work for all widgetsets, )-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Juha Manninen via lazarus]

On Mon, Nov 29, 2021 at 1:32 PM Ondrej Pokorny via lazarus <
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.
It allows a Frame to stand without a parent in the designer or even at
runtime in some hypothetical situation(?).
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.


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().

Juha
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Martin Frb via lazarus]

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.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Ondrej Pokorny via lazarus]

On 29.11.2021 12:32, Michael Van Canneyt via lazarus wrote:

On Mon, 29 Nov 2021, Martin Frb via lazarus wrote:

On 29/11/2021 12:05, Michael Van Canneyt via lazarus wrote:


What do you mean 'artificial restrictions' ?  The above is quite 
standard.


IMHO  "if csLoading" tests are also "quite standard"

"If HandleCreated" exist too, not sure how widespread

"accessing canvas"  outside paint, is discouraged.


Well, as I understood it, painting code will not work on Mac outside the
paint event, so only using canvas inside paint should be standard ?


You can still use the Canvas outside Paint for measuring. But not for 
painting. Painting outside Paint on Windows it is problematic as well.


The "use the Canvas outside Paint for measuring" is valid of course only 
as long as Canvas is there or can be created - and it can be created 
when the handle is created or can be created. And a (normal) control's 
handle can be created only when a parent is set.


That is the problem - the code tries to access canvas when the control's 
handle cannot be created.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Michael Van Canneyt via lazarus]

On Mon, 29 Nov 2021, Martin Frb via lazarus wrote:


On 29/11/2021 12:05, Michael Van Canneyt via lazarus wrote:


What do you mean 'artificial restrictions' ?  The above is quite 
standard.


IMHO  "if csLoading" tests are also "quite standard"

"If HandleCreated" exist too, not sure how widespread

"accessing canvas"  outside paint, is discouraged.


Well, as I understood it, painting code will not work on Mac outside the
paint event, so only using canvas inside paint should be standard ?
Reading is of course possible, I suppose.

Michael.-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Ondrej Pokorny via lazarus]

On 29.11.2021 11:32, 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).



So maybe your patch should be extended, to only do that, if the 
control is in "designtime" state?


Yes, definitely add a condition to check the designtime state.

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.


So I would encourage the component author to rewrite his code.

Ondrej


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Martin Frb via lazarus]

On 29/11/2021 12:05, Michael Van Canneyt via lazarus wrote:


What do you mean 'artificial restrictions' ?  The above is quite 
standard.


IMHO  "if csLoading" tests are also "quite standard"

"If HandleCreated" exist too, not sure how widespread

"accessing canvas"  outside paint, is discouraged. Though other uses of 
the "Handle" may exist outside paint.

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Martin Frb via lazarus]

On 29/11/2021 11:36, Michael Van Canneyt wrote:



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 ?


Well, if your code works now, then apparently it does not access the 
handle/canvas before setting a parent?

Which also means, you do not "show" the frame, before it has a parent.

1)
With Juha's current patch: Yes. => Afaik this adds no restrictions.
=> Except, if you are waiting for an Exception, because you expect it to 
fail. ;)


2)
If we add a "if designtime" around Juhas code, still nothing changes for 
your code. Since then runtime behaviour would be exactly as it currently is.


3)
If we add
   If (not designtime) and (ParentWindow = nil) then raise Exception();
afaik still nothing changes (except for the error message).
Because currently, without Parent/ParentWindow it will fail to create 
the Handle (Actually, may need to be tested for all WidgetSets).



If your code creates a Frame that during its creation (reading from lfm, 
or calls by other code) triggers any component to access the canvas, or 
otherwise needing a handle,

then your code would fail already (without Juha's Patch).

With the current Patch, such an "canvas" access would create a handle 
(it might not make it visible, but it could even do that).
If that handle is created, and you set a Parent, then the handle would 
have to be discarded.


So unless a frame should be able to be visible shown at runtime as if it 
was a Form of itself, any handle created without parent is created to be 
discarded again.
Such a handle would only serve the purpose to allow incorrect code to 
"get away" (I.e. to draw text on an invisible canvas, that will never 
become visible).


Question is:
- Should that be allowed?
- Should components access the canvas in "csLoading", or "if not 
HandleCreated"  (unless they indent for the Handle to be created at that 
time, and therefore are aware if that is possible)



--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Michael Van Canneyt via lazarus]

On Mon, 29 Nov 2021, Juha Manninen via lazarus wrote:


On Mon, Nov 29, 2021 at 12:36 PM Michael Van Canneyt via lazarus <
lazarus@lists.lazarus-ide.org> wrote:



On Mon, 29 Nov 2021, Martin Frb via lazarus wrote:

- The property accesses "canvas" => that triggers asking for a handle
(which is created based on CreateParams)




Ah yes, Canvas.
TStringGrid also uses Canvas a lot, but apparently not in a property setter.


I often create a frame in code (so no parent) which is then placed on a

form.
Will this scenario still work ?



Yes, after my fix it still works.
It is better *not* to add other artificial restrictions. They would bring
no benefit as Martin noted.


What do you mean 'artificial restrictions' ?  The above is quite standard.

Michael.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Juha Manninen via lazarus]

On Mon, Nov 29, 2021 at 12:36 PM Michael Van Canneyt via lazarus <
lazarus@lists.lazarus-ide.org> wrote:

>
> On Mon, 29 Nov 2021, Martin Frb via lazarus wrote:
> > - The property accesses "canvas" => that triggers asking for a handle
> > (which is created based on CreateParams)
>

Ah yes, Canvas.
TStringGrid also uses Canvas a lot, but apparently not in a property setter.


I often create a frame in code (so no parent) which is then placed on a
> form.
> Will this scenario still work ?
>

Yes, after my fix it still works.
It is better *not* to add other artificial restrictions. They would bring
no benefit as Martin noted.

Juha
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Michael Van Canneyt via lazarus]

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.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Martin Frb via lazarus]

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?

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] TFrame improvements

[Juha Manninen via lazarus]

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).

There are also improvements for a custom Frame installed as a component in
the palette.
See:
 https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39488

The improvements will be merged to 2.2.

Regards,
Juha
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus