Board index » delphi » When is Sender: NOT TObject

When is Sender: NOT TObject

I'm a Delphi (but not Pascal) newbie, and have been given the task
of modifying a problematic Delphi 1.0 application in a short period
of time.  While I've been able to grok the program's functioning,
I'm a little bit unfamiliar with the structure of the .PAS files, in
particular the Sender parameter.

Throughout the application, and indeed in all the demos and
components I've seen so far, the Sender is always TObject.

When is Sender: NOT TObject?

--
jeffw...@swva.net
SPAMMER WARNING:  I don't munge my e-mail address because I like
being the jack-booted anti-spammer.  Spam me at the risk of your
connectivity.  http://www.cauce.org

 

Re:When is Sender: NOT TObject


Jeff Wynn <jeffw...@swva.net> skrev i artiklen
<MPG.109fe6d4a3c35f05989...@news.vt.edu>...

Quote
> Throughout the application, and indeed in all the demos and
> components I've seen so far, the Sender is always TObject.
> When is Sender: NOT TObject?

I would say that Sender is always TObject.
Sender is just name, but TObject can be anything: TLabel, TEdit, TButton,
you name it.
Sender is just Delphi's "default" label for the parameter passed in the
components event procedures.
Did that help?

Finn Tolderlund

Re:When is Sender: NOT TObject


In article <MPG.109fe6d4a3c35f05989...@news.vt.edu>, jeffw...@swva.net (Jeff

Quote
Wynn) writes:

>Throughout the application, and indeed in all the demos and
>components I've seen so far, the Sender is always TObject.

>When is Sender: NOT TObject?

The TObject class is the default ancestor of all Delphi objects.
So Sender is always a_descendant_of TObject
use the <as> or <is> keywords to determine which class sender actually is

eg (Sender as TEdit).Text:='You clicked on this control';

or safer

 If sender is TEdit then
(Sender as TEdit)...

very useful!!

Cheers
John Parsons

Cray Chicken: Crosses faster than any other chicken, but if you don't dip it
in liquid nitrogen first, it arrives on the other side fully cooked!

Re:When is Sender: NOT TObject


In article <MPG.109fe6d4a3c35f05989...@news.vt.edu>, jeffw...@swva.net (Jeff

Quote
Wynn) writes:
>I'm a Delphi (but not Pascal) newbie, and have been given the task
>of modifying a problematic Delphi 1.0 application in a short period
>of time.  While I've been able to grok the program's functioning,
>I'm a little bit unfamiliar with the structure of the .PAS files, in
>particular the Sender parameter.

>Throughout the application, and indeed in all the demos and
>components I've seen so far, the Sender is always TObject.

>When is Sender: NOT TObject?

Never (as far as the code is concerned) & usually (as far as the programmer is
concerned) <g>

The Sender can be any object capable of triggering an event. Because of the
wide range of objects which may trigger an event, Delphi must choose a type
which is compatible with all events. The lowest common capability (ie highest
on the inheritance tree) is a TObject. A TObject will be compatible with any
other object in terms of its use as a Sender parameter. But although the
parameter type is a TObject, a TButton or a TPanel could initiate the event and
be the parameter of the event handler. That is, that the Sender may be a
TButton but the Delphi compiler accepts it and assumes it is a TObject.

But the TObject may not have all the properties and methods you may want to
access / use, for example. a TObject does not have a Caption (even though a
TButton does) so when you attempt to access the Sender.Caption, Delphi says "
an object does not have a Caption so - Undefined". But you _know_ that the
particular descendant of the TObject you are using (ie a TButton) does have a
Caption. So typecast the sender to a TButton (or the highest object in the
inheritance tree which does have a Caption ie a TControl). The compiler will
then happily accept :- TButton(Sender).Caption := 'Got an Event';

Remember that type-casting in Delphi does not change anything in memory, it
just makes the compiler happy.

Also remember that a property / method is effectively accessed by a pointer
offset from the pointer to the object. Caption is at a certain offset from the
object's pointer (ie de-referenced name). TButton has an accessible (with no
GPF) storage for a string at the Caption offset, the same offset on a TObject
would be into protected memory and would cause a GPF, so the compiler prevents
you accessing it. If you type-cast to a TButton and _then_ pass a TObject to
the Sender, then you would be attempting to access protected memory at the
Caption offset - so GPF. That's why the type-cast is usually protected by using
(Sender as TButton).Caption. If the Sender is not a TButton you get a standard
exception which is handled in a better way than a GPF - you could even catch
the exception yourself.

Alan Lloyd
alangll...@aol.com

Re:When is Sender: NOT TObject


Hi,

I think Sender will not be TObject when it is Nil. I used this sometime
when triggering a button click from code. I wanted to tell the OnClick
handler that it was triggered not by a component so I called it this
way:
Button1Click(nil);
Sender = Nil;

Remember: Event handlers are ordinary procedures, right?

Bye,
    Felipe Rocha Machado
    GPS Tecnologia Ltda.

Quote
Jeff Wynn wrote:
> I'm a Delphi (but not Pascal) newbie, and have been given the task
> of modifying a problematic Delphi 1.0 application in a short period
> of time.  While I've been able to grok the program's functioning,
> I'm a little bit unfamiliar with the structure of the .PAS files, in
> particular the Sender parameter.

> Throughout the application, and indeed in all the demos and
> components I've seen so far, the Sender is always TObject.

> When is Sender: NOT TObject?

> --
> jeffw...@swva.net
> SPAMMER WARNING:  I don't munge my e-mail address because I like
> being the jack-booted anti-spammer.  Spam me at the risk of your
> connectivity.  http://www.cauce.org

Re:When is Sender: NOT TObject


In article <19981027172652.04668.00000...@ngol06.aol.com>, a being
named Alan Lloyd is said to have written...

Quote

> In article <MPG.109fe6d4a3c35f05989...@news.vt.edu>, jeffw...@swva.net (Jeff
> Wynn) writes:

> >I'm a Delphi (but not Pascal) newbie, and have been given the task
> >of modifying a problematic Delphi 1.0 application in a short period
> >of time.  While I've been able to grok the program's functioning,
> >I'm a little bit unfamiliar with the structure of the .PAS files, in
> >particular the Sender parameter.

> >Throughout the application, and indeed in all the demos and
> >components I've seen so far, the Sender is always TObject.

> >When is Sender: NOT TObject?

> Never (as far as the code is concerned) & usually (as far as the programmer is
> concerned) <g>

I guess I just wondered why it always in the code like
this:

procedure FooForm.FooMethod(Sender: TObject)

and never this:

procedure BarForm.BarMethod(Sender: TSomeOtherObject)

It seems somewhat silly to have to declare the Sender
parameter as TObject if the Sender parameter is *always*
TObject.

I guess it is Just One Of Those Things<tm>.

<SNIP helpful discussion about using Sender as descendant of
TObject>

Quote

> Alan Lloyd
> alangll...@aol.com

--
jeffw...@swva.net
***********SPAMMER WARNING**************
I don't munge my e-mail address because I like being the jack-booted
anti-spammer.  Spam me at the risk of your connectivity.
http://www.cauce.org

Re:When is Sender: NOT TObject


In article <3636F93B.1D653...@pemail.net>, a being named Felipe
Rocha Machado is said to have written...

Quote
> Hi,

> I think Sender will not be TObject when it is Nil. I used this sometime
> when triggering a button click from code. I wanted to tell the OnClick
> handler that it was triggered not by a component so I called it this
> way:
> Button1Click(nil);
> Sender = Nil;

> Remember: Event handlers are ordinary procedures, right?

Ahhh.  Perhaps I'm beginning to see the light.
What does the Sender parameter say in the Button1Click
procedure?

Does it look like this:

procedure Form1.Button1Click(Sender: nil)?

--
jeffw...@swva.net
***********SPAMMER WARNING**************
I don't munge my e-mail address because I like being the
jack-booted anti-spammer. Spam me at the risk of your connectivity.
http://www.cauce.org

Re:When is Sender: NOT TObject


Jeff Wynn <jeffw...@swva.net> skrev i artiklen
<MPG.10a10af356a1e3c8989...@news.vt.edu>...

Quote
> It seems somewhat silly to have to declare the Sender
> parameter as TObject if the Sender parameter is *always*
> TObject.

It isn't silly to declare Sender as TObject, because it IS TObject.
And it has to be declared as something, just like every other variables
which are used as parameters in a procedure.
And because Sender must be declared it is therefore declared as TObject.
Simple really.

Re:When is Sender: NOT TObject


Quote
Jeff Wynn wrote:
> It seems somewhat silly to have to declare the Sender
> parameter as TObject if the Sender parameter is *always*
> TObject.

It has to be declared as something, and this is the most flexible choice.

The declaration of TObject allows any component to trigger a common event and pass
itself as "Sender".  E.g., I have a form where the Click or Change event of all
controls is directed to a single notification method.  This is straightforward
because all components can be cast as TObjects.  Were it implemented such that
button click notifications were "ButtonClick( Sender as TButton )" and ListBox
clicks were "ListboxClick( Sender as TListBox )", and so forth, it would be a lot
messier to reuse event handlers.

Re:When is Sender: NOT TObject


In article <MPG.10a10af356a1e3c8989...@news.vt.edu>, jeffw...@swva.net (Jeff

Quote
Wynn) writes:
>It seems somewhat silly to have to declare the Sender
>parameter as TObject if the Sender parameter is *always*
>TObject.

If you look closer into the activity of an event in an object class you have a
private variable which has to be of a procedural type to store the event
handler pointer / name, and  a property of that type with protected or
published protection.

If you had different types for the parameter of the same event of every
different object, you would have to have an awful lot of types defined. And you
would have to remember / look-up every time you used it. Type-casting is much
simpler.

Furthermore, common event handlers for the same event for different objects,
would be more difficult.

The clincher is really that it is safe to declare it as a TObject even if what
is passed is nearly always a descendant of a TObject.

This is one of those things which become clearer and more logical when one has
had more experience in the language. That sounds quite patronising but it is
not meant that way. Only now do I start to appreciate and understand things I
thought odd and illogical in my earlier Delphi days <g>

Alan Lloyd
alangll...@aol.com

Re:When is Sender: NOT TObject


Quote
Jeff Wynn wrote:

> Throughout the application, and indeed in all the demos and
> components I've seen so far, the Sender is always TObject.

> When is Sender: NOT TObject?

This basically says. "Sender is a pointer to a class whose (possibly
indirect) ancestor is TObject." Since TObject is the only root of the
tree.. everything's root is TObject.

The value of this is perhaps when you have a callback from a
componenent, where you need to make explicit that it's come from a
TComponent descendant:

type
TComponentNotifyEvent=procedure(Sender:TComponent);of object;

MH.

--
Martin Harvey

mailto:mar...@aziraphale.demon.co.uk
http://www.harvey27.demon.co.uk/mch24/

Undoubtedly, someone can learn Object Oriented Programming from
reading code - after all Alan Kay learned OO by deciphering
an 80 page Simula program thinking it was Algol.
However, most people are not in the same league as Alan.
- Bjarne Stroustrup

Re:When is Sender: NOT TObject


Quote
AlanGLLoyd wrote:

<loads of stuff>

Quote
> Alan Lloyd
> alangll...@aol.com

Lovely explanation Alan. The only thing I'd object to is your use of the
phrase "protected memory". Perhaps it would be better to say that If you
write Sender.Caption where sender is declared to be of type TObject,
then the compiler cannot calculate the correct memory address to look
at, since TObject's don't have a caption. This ties up nicely with the
concept of LValues and RValues :-)

MH.

--
Martin Harvey

mailto:mar...@aziraphale.demon.co.uk
http://www.harvey27.demon.co.uk/mch24/

Undoubtedly, someone can learn Object Oriented Programming from
reading code - after all Alan Kay learned OO by deciphering
an 80 page Simula program thinking it was Algol.
However, most people are not in the same league as Alan.
- Bjarne Stroustrup

Re:When is Sender: NOT TObject


On Wed, 28 Oct 1998 11:05:57 -0500, jeffw...@swva.net (Jeff Wynn)
wrote:

Quote
>I guess I just wondered why it always in the code like
>this:
>procedure FooForm.FooMethod(Sender: TObject)
>It seems somewhat silly to have to declare the Sender
>parameter as TObject if the Sender parameter is *always*
>TObject.

Well, since all Delphi VCL objects descend from TObject, they're all
compatible types, which means, you can pass any TObject descendant
here as an actual parameter.

What I use the Sender parameter for is to distinguish the actual
caller of an event handler, if I have one set up generally. Let's say
you have 100 buttons, and everyone should have a click event handler,
and all of them are practically the same. What you can do is code
*one* click event handler, assign it to all the 100 button's click
event, and distinguish which button actually got clicked by evaluating
the Sender parameter, e.g. to do something special with Button34 or
so.

procedure TForm1.MyButtonHandler(Sender: TObject);
begin
   if (TButton(Sender) = Button34) then
      (* do something special *)
   else
      (* do normal processing *)
end;

Marc

--------------------------------------------------------------------------
Marc Scheuner                            Berner Versicherungen, Dept. ISV
May the Source be With You               Laupenstrasse 27
marc.scheu...@berner.ch                  CH-3001 BERNE, Switzerland
--------------------------------------------------------------------------

Re:When is Sender: NOT TObject


On Wed, 28 Oct 1998 11:11:08 -0500, jeffw...@swva.net (Jeff Wynn)
wrote:

Quote
>In article <3636F93B.1D653...@pemail.net>, a being named Felipe
>Rocha Machado is said to have written...
>> Hi,

>> I think Sender will not be TObject when it is Nil. I used this sometime
>> when triggering a button click from code. I wanted to tell the OnClick
>> handler that it was triggered not by a component so I called it this
>> way:
>> Button1Click(nil);
>> Sender = Nil;

>> Remember: Event handlers are ordinary procedures, right?

>Ahhh.  Perhaps I'm beginning to see the light.
>What does the Sender parameter say in the Button1Click
>procedure?

>Does it look like this:

>procedure Form1.Button1Click(Sender: nil)?

>--

Should be more like this:

procedure Form1.button1click ( Sender : TObject );
// This is the declaration of the procedure, and it will
// definitely want a TObject of some shape, size of form
begin
    dosomethingreallyclever;
end;

procedure form1.edit1.onchange ( sender : tobject );
// just as an example, really... calls button1click with NIL as sender
begin
   if foo = bar then
      button1click ( nil );
end;

The procedure declaration of button1click must have sender declared as
tobject. That's what it is supposed to be, after all :-) When you call
the button1click procedure programatically, you can send NIL as the
parameter, or an instance of any one of TObject's descendants. Whether
it really matters what kind object  (or NIL for that matter) you pass
as Sender really depends on what button1click is using it for. In most
cases, button1click won't give a shit (hence you can get away with
NIL as sender), but you can get really clever with the Sender
parameter if you want to. If button1click starts doing any "with
sender as tbutton do ..." tricks, for instance, Ii imagine that a
sender of NIL would be asking for trouble - unless you checked to see
that it wasn't NIL before you started using it... you get the idea. As
has been pointed out, the whateverobject.someevent (sender : tobject)
stuff is really just another plain-vanilla procedure with just another
plain-vanilla parameter when you get right down to it...

St?le Sannerud

Re:When is Sender: NOT TObject


In article <3637512E.6BAEC...@aziraphale.demon.co.uk>, Martin Harvey

Quote
<mar...@aziraphale.demon.co.uk> writes:
>Lovely explanation Alan. The only thing I'd object to is your use of the
>phrase "protected memory". Perhaps it would be better to say that If you
>write Sender.Caption where sender is declared to be of type TObject,
>then the compiler cannot calculate the correct memory address to look
>at, since TObject's don't have a caption. This ties up nicely with the
>concept of LValues and RValues :-)

I accept your expertise and knowledge, Martin. I tend to use "pragmatic
concepts" when I'm explaining of things - ie It helps for me to think of it
that way, but it may not be exactly correct in some areas which I consider a
bit non-essential to the overall concept. And I think I meant "protected by the
compiler" - which was {*word*194} of me to use such a phrase ("protected memory")
ambiguously.

If I knew exactly what an LValue or RValue was when I met it I'm sure I'd agree
with you <gg>, but I'm only a simple mechanical / electronic / aeronautical
engineer come lately to computing <g>.

Alan Lloyd
alangll...@aol.com

Go to page: [1] [2]

Other Threads