• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 224
  • Last Modified:

NEWBIE: Where does a delegated method "occur"?

Dear Experts,

I'm a C# newbie trying to understand events.  Please take this example:

I have a Clock class, which declares an event.  I have a DisplayTime class, which registers a method with the Clock class event. (Lifted from O'Reilly's Programming C#, thank you.)

When that method executes, is it correct to think of it as the Clock class calling a method inside of the DisplayTime class?  Or is it better to think of it as the Clock method itself executing a chunk of code that happened to come from the DisplayTime class originally?

Specifically, can the method refer to instance and class variables inside of the original DisplayTime class, which are not defined in the method itself?  

Yours in Slowly-Subsiding Confusion,
BrianMc1958
0
BrianMc1958
Asked:
BrianMc1958
  • 3
  • 2
3 Solutions
 
Mike TomlinsonMiddle School Assistant TeacherCommented:
A little bit of both!

The method inside DisplayTime being run will actually execute in the thread that the Clock class raised the event from.  This may be different from your main UI thread (if that is what DisplayTime is) and require the use of Invoke()/Delegates to marshal the call to the correct UI thread where it is safe to update your GUI components.

But...the method is still encapsulated by the DisplayTime class and can only refer to any members that it could normally access as if it were run from DisplayTime itself.  Many times though, an event will send a reference to the object that generated the event (often called "sender") via event parameters so that the method being executed can access the state of the object that raised the event.
0
 
renjurdevanCommented:
we can say delegate as typed function pointer!! ie in C++ we cant distingush a function pointer either with the return type or with parametes!! but in c# we can distigush. Delegates are class wchich has ability to store the signature alone!


if we points a function either static or instance it will be called when attached events fired or called!! You have chaining of delegate which calls methods in queueing manner!! all the function should be similar in signature which is same as delegate signature!!

Regards
Renju
0
 
BrianMc1958Author Commented:
It's the next morning.  The coffee isn't ready yet.  I'm still pondering this.  Thanks...
0
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

 
BrianMc1958Author Commented:
OK.  I think that answers that.  So the DisplayTime method CAN update instance variables in DisplayTime, even though it may be running in the Clock thread?  Is that right?  (We'll leave HOW that might happen for a much later question...)

If I could ask a follow-up, I had noticed that the sender typically passes back a reference to itself ("this").  I didn't know if that was simply to tell the receiver which class responded, or if it was intended that the receiver would actually use that reference to access public methods and variables in the sender.  If so, why return EventArgs (did I spell that right?) as a separate response?

Given that I'm loading on more of a question, I'll double the points, too...
0
 
Mike TomlinsonMiddle School Assistant TeacherCommented:
"So the DisplayTime method CAN update instance variables in DisplayTime, even though it may be running in the Clock thread?"

Correct.

You just need to be aware of what types of variables you should and should not update from a separate thread.  Otherwise, you have to do the cross-thread dance.  This has a whole slew of other considerations such as race-conditions, thread synchronization, atomic operations, etc...  all dependent upon that apps particular scenario.  =)

"We'll leave HOW that might happen for a much later question..."

This generally only occurs if the Clock class is directly creating another thread...or indirectly by using a threaded Timer (not the one from the ToolBox!).

"I didn't know if that was simply to tell the receiver which class responded, or if it was intended that the receiver would actually use that reference to access public methods and variables in the sender."

That is completely dependent upon the architecture of the application...it is possible to send "null" back thru the sender so you should always check it first.  You can declare an event that returns NO parameters at all as well...

"If so, why return EventArgs (did I spell that right?) as a separate response?"

That actually is more a factor of the way the .Net framework itself is setup with OOP in mind and just the way they created the "base" event.  You can derive a class from EventArgs to pass in your event.  This is simply to give "quick" access to some fields you think are relevant to your event.  For instance, the MouseDown() event tells you what button was pressed.
0
 
BrianMc1958Author Commented:
As is frequently the case, I am very grateful you EE folks would take the time to answer my question/s so clearly and completely.

--BrianMc1958
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now