I don't understand the logic behind TControl.Click:

procedure TControl.Click;
begin
   //DebugLn(['TControl.Click ',DbgSName(Self)]);
   if (not (csDesigning in ComponentState)) and (ActionLink  nil) and
      ((Action=nil) or (@FOnClick  @Action.OnExecute) or
Assigned(FOnClick)) then
     ActionLink.Execute(Self)
   else
   if Assigned(FOnClick) then
     FOnClick(Self);
end;

This IMO will invoke ActionLink.Execute if (a different) FOnClick is assigned - so far okay. But FOnClick will *not* be invoked then (even if different), and it will be invoked *always* in design state.

Is it really okay to invoke an user-supplied OnClick handler in design state?

What about something like this:

   if (csDesigning in ComponentState) then
     exit; //nothing called in design state
   if (ActionLink  nil)
     and ((Action=nil) or (@FOnClick  @Action.OnExecute) then
     ActionLink.Execute(Self); //only if different from FOnClick
   if Assigned(FOnClick) then //eventually also: if not handled?
     FOnClick(Self); //always if assigned
end;

I also wonder what's the difference or relationship between Action and ActionLink - can somebody explain? Does ActionLink (when assigned) take precedence over Action?

DoDi

No.
User supplied OnClick handlers are fake methods and that's why "Assigned" is used instead of "FOnClicknil". Thus user handlers are *not* invoked.
Only real methods are invoked. That means custom component handlers are invoked.

See TControl.GetAction.
Then lol.

Mattias

Off your topic

Mattias Gaertner wrote

"Assigned" is used instead of "FOnClicknil"

What is different between check the Method fields ? "Assigned(FOnClick)" and "FOnClicknil"

Thanks

Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111001/6cc44805/attachment.html>

http://wiki.lazarus.freepascal.org/IDE_tricks#Events_.28Method_properties.29_in_the_Object_Inspector

Mattias

On Sat, Oct 1, 2011 at 10:13 AM, Mattias Gaertner <

Thanks, but not understand it, but i will to check and correct my components code.

Best Regard

Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111001/16554c10/attachment.html>

Maybe I overlook something, but
@FOnClick is the address of the variable holding the method reference (or nil)
so is @Action.OnExecute

So when can they ever be equal?

Should that maybe compare FOnClick Action.OnExecute ?

Also is that supposed to be a shortcut, saving the call, or is that indeed supposed to modify behaviour?
Even if the 2 callbacks are pointing to the same method, calling Action.OnExecute, will call the callback with Sender=TheAction, while FOnClick gets the current object.

You are right.

Should that maybe compare FOnClick Action.OnExecute ?

That would miss difference in Data.
I added a CompareMem.

Also is that supposed to be a shortcut, saving the call, or is that indeed supposed to modify behaviour?

Good question.
I guess it would be enough to check (not (csDesigning in ComponentState)) and (ActionLink nil).

Maybe the Delphi docs have an answer.

Even if the 2 callbacks are pointing to the same method, calling Action.OnExecute, will call the callback with Sender=TheAction, while FOnClick gets the current object.

Mattias

What do you don't understand?

Mattias

Strange, on the page it says:

if OnMyEvent nil then OnMyEvent(...);// wrong, because it checks Data too if OnMyEvent = NewValuethen exit;// wrong, because it compares only Code

So I compiled (to assembler) 32 bit:

Comparison with nil (expect to check code + data, as told above) Comparison with other method (expect code only)

But in both cases it tests one long entry (testl or cmpll). so the same amount of data. It doesn't look that nil checks code+data?

# [33] if OnDeactivate nil then;
movl -8(%ebp),%eax
movl 980(%eax),%eax
testl %eax,%eax
.Lj6:
.Ll3:
# [34] if OnClose = nil then;
movl -8(%ebp),%eax
movl 956(%eax),%eax
testl %eax,%eax
.Lj8:
.Ll4:
# [35] if OnDeactivate = OnCreate then;
movl -8(%ebp),%eax
movl -8(%ebp),%edx
movl 980(%eax),%eax
cmpl 972(%edx),%eax

On Sat, Oct 1, 2011 at 10:05 AM, Mattias Gaertner <

In my knowledge, Mehtod of the object, is pointer to the Procedure and pointer to that Object, i do not know if that correct. Now in design time, the code not set, that is ok, but data set to fake pointer, what is it?.
Maybe if i want to understand i must follow the IDE designer and read it, or you can explain it to me :) .

Thanks
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111001/4368ebeb/attachment-0001.html>

2011/10/1 Mattias Gaertner :

There is also a function CompareMethods.

[...] In my knowledge, Mehtod of the object, is pointer to the Procedure and pointer to that Object, i do not know if that correct.

Correct.

Now in design time, the code not set, that is ok, but data set to fake pointer, what is it?.

In case of Lazarus it is a TJITMethod.

Maybe if i want to understand i must follow the IDE designer and read it, or you can explain it to me :) .

see designer/jitforms.pp
TJITMethod stores the owner object and method name. At runtime this information is normally stored in the method data and the VMT of the class of the method owner.

Mattias

Yes. But it needs typecasts and does the same, so it does not matter which one is used.

Mattias

You are right. It seems it was changed in the compiler. I will update the wiki.

Mattias

Yes.

[...]

Mattias

This wiki page is not the documentation for methods in general. See the fpc docs for that.
The wiki page is more like an FAQ.

Mattias

...

further more:

ActionLink.Execute is virtual

So comparing with the OnExecute method pointer is at the very least insufficient.

If ActionLink.Execute is overridden, it could call/do anything.

I would suggest to drop that check entirely

SVN Blame shows that it's been there for a long time, and always had the @FOnClick => so it never triggered in the past, and there never was a bug, while it did not trigger.

Then the question remains, why Action hides the OnClick handler, at runtime? Is this required by Delphi compatibility?

Thanks for the hint :-)

DoDi

No.
You could say: Method pointers are handled differently in mode Delphi and mode ObjFPC.
And since the LCL uses mode objfpc the @event is unambiguous and therefore wrong as Martin wrote.

Thanks for pointing out.
Fixed by using CompareMethods.

It seems Delphi calls OnClick when it is set and differs from the Action. I did that.

Why? How?

Mattias

The many "Do not ..." hints are not really helpful without understanding method pointers and Assigned().

In detail I supposed that FOnClicknil will never work properly, on no method pointer, because it only checks the first pointer (explanation in Delphi newsgroups).

The documentation of Assigned() also is not really helpful, there's no explanation of the real difference vs. Pnil. There seem to exist more differences, e.g. with the "dummy" event handler value at design time?

DoDi

True. But it seems Delphi does the same.

I would suggest to drop that check entirely

Why?
Do you have a real case where it hurts?

SVN Blame shows that it's been there for a long time, and always had the @FOnClick => so it never triggered in the past, and there never was a bug, while it did not trigger.

Well, this allows many conclusions. ;)

Mattias

To expand the execute of Action, So Action.Execute run before Button.OnClick.
And that done in the our application Forms, not break the compatibility with Delphi.

Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111001/bfdee6c1/attachment.html>

Really?

AFAIK method pointers are handled differently in Delphi and FPC, where FPC requires @FOnClick to get the value stored in FOnClick, where Delphi guesses whether FOnClick should invoke the method or return the value.

> Should that maybe compare FOnClick Action.OnExecute ? That would miss difference in Data. I added a CompareMem.

IMO the comparison worked as-is, as found in several places in the LCL.

What about:

function TControlActionLink.IsOnExecuteLinked: Boolean;
begin
   Result := inherited IsOnExecuteLinked
             and (FClient.OnClick = Action.OnExecute);
end;

No :-(

> Even if the 2 callbacks are pointing to the same method, calling > Action.OnExecute, will call the callback with Sender=TheAction, while > FOnClick gets the current object.

Looks as if Execute should be overridden in TControlActionLink!

DoDi

Please test the LCL trunk version for compatibility.

Mattias

To use the control as Sender, at least when it equals the control's OnClick.

At least everything would be more clear, when in the case of different control.OnClick and action.Execute the OnClick would take precedence. Then it can be assumed that the OnClick handler expects a control, while equal handlers more probably indicate and Execute handler, expecting an Action as Sender. Then Execute doesn't deserve an override.

DoDi

That is the case since revision 32583.

Then it can be assumed that the OnClick handler expects a control, while equal handlers more probably indicate and Execute handler, expecting an Action as Sender. Then Execute doesn't deserve an override.

Mattias

Delphi compares

   DelegatesEqual(@FClient.OnClick, @Action.OnExecute)));

what looks good, except that DelegatesEqual accepts two Pointers - what causes the well known comparison problems.

At least FOnClick is preferred over Execute:

procedure TControl.Click;
begin
{ Call OnClick if assigned and not equal to associated action's OnExecute.
If associated action's OnExecute assigned then call it, otherwise, call OnClick. }
if Assigned(FOnClick) and (Action nil) and not
DelegatesEqual(@FOnClick, @Action.OnExecute) then
FOnClick(Self)

   else if not (csDesigning in ComponentState) and (ActionLink  nil) then
     ActionLink.Execute(Self)
   else if Assigned(FOnClick) then
     FOnClick(Self);

end;

DoDi

> Then the question remains, why Action hides the OnClick handler, at > runtime? Is this required by Delphi compatibility? Yes.

No, sorry. Both D7 and XE prefer OnClick (see my other mail).

DoDi