C#•2y ago

✅ Design of events

Hi!
I have a question about utilization of events. Don't know many real life production examples by myself, but counting on your experience

I've noticed that EventHandler delegate takes two parameters: object sender and EventArgs or other defined type. That means that in subscribers we can't be sure what is the sender and what are its properties/methods. So what's the main purpose (by design) of this "sender" parameter, shall it be used to check what type it is and take actions based on that? I am aware that I can create my own type of event instead of using EventHandler, but anyway I'm curious about the real life usage of the sender object.

Angius•7/25/24, 3:47 PM

That's specifically about WPF events?

Angius•7/25/24, 3:47 PM

If so, then the sender is a reference to the control that called the event

Angius•7/25/24, 3:48 PM

Like, a click event of a button will have a reference to that button as the sender

Angius•7/25/24, 3:53 PM

Other than that, the sender is generally a reference to the calling class

TomOP•7/25/24, 4:00 PM

Thanks, I didn't mean WPF specific but is it a general rule that subscribers should be prepared that event can be raised by different type of classes? Otherwise, I think we could use other handler like:
.
So the main reason of my question is that I want to understand why authors utilize this ambigous "object" as a sender. Probably there is some logic behind that but I know too litle real life examples to deduct that.

Angius•7/25/24, 4:01 PM

There's a override that takes the type of the events object

Angius•7/25/24, 4:01 PM

As to why...?

Angius•7/25/24, 4:01 PM

Old code would be my best bet

Angius•7/25/24, 4:02 PM

Someone did it this way some days, nobody bothered to update it because it would be a breaking change or whatever, and that's where we're at

Angius•7/25/24, 4:02 PM

For custom code, I would probably just not use but rather s and

Action

Action

s, or a named delegate instead

MODiX•7/25/24, 4:11 PM

Angius

REPL Result: Failure

Console Output

Exception: ExitException

Compile: 705.722ms | Execution: 68.717ms | React with ❌ to remove this embed.

Angius•7/25/24, 4:11 PM

Something like this, without using

TomOP•7/25/24, 7:29 PM

thx for your input and the example

Probably I will have to find my way of dealing with that, but that comes with time

TomOP•7/25/24, 7:29 PM

good to know many ways to solve things

SleepWellPupper•7/25/24, 7:47 PM

It's because that's the common abstraction and simplest to code against for the purpose of the parameter, which you have summarized perfectly.

SleepWellPupper•7/25/24, 7:48 PM

I agree with @ZZZZZZZZZZZZZZZZZZZZZZZZZ , you'd want an event handler delegate that matches the specific usecase. Sometimes that includes checking the sender due to subscriptions to several publishers of the same event.

canton7•7/26/24, 7:56 AM

Also, that pattern comes from C# 1, before we had generics

canton7•7/26/24, 7:58 AM

But, generics will only take you so far. Sure you could do:

But what if A was subclassed?

Then you could do:

And that parameter would be typed as an instance of , even though it was an instance of which raised it.

That happens loads in UI frameworks, where events are defined by classes near the base of the object hierarchy, but you often interact with classes much further down

canton7•7/26/24, 8:00 AM

Obviously if you subscribe to you expect the parameter to be an instance of . You're not going to get some other control raising that event and inserting itself as the parameter.

canton7•7/26/24, 8:01 AM

But sometimes you have a list of 20 textboxes, and you want to do something when the text changes in any of them, and you don't want to define 20 handlers. So you define a single handler, and you use that parameter to interact with the specific textbox which raised the event

AAngius For custom code, I would probably just not use `EventHandlers` but rather `Func`...

canton7•7/26/24, 8:03 AM

Do bear in mind the reason that the pattern exists, which is forwards compatibility. You can't add extra parameters to an

Action

Action

without it being a breaking change, but you can add additional properties to an subclass

AAngius There's a `EventHandler<T>` override that takes the type of the events object

canton7•7/26/24, 8:04 AM

That's why

TomOP•7/26/24, 5:37 PM

Thanks for your insight @canton7.

Ccanton7 But sometimes you have a list of 20 textboxes, and you want to do something when...

TomOP•7/26/24, 5:40 PM

then won't having specific TextBox as a sender class be good enough? However I may imagine that there are kinds of text boxes which you deal with differently...

canton7•7/26/24, 6:00 PM

Isn't that is what happens though?

TomOP•7/29/24, 3:07 PM

@canton7 Not sure I understood you, as I mean typing instead of , (or smth like that).
But anyway, I'm now playing around a bit with Avalonia UI and its events, which may give me more insight, then I may "feel" more what you have writtten.
Thank you both @ZZZZZZZZZZZZZZZZZZZZZZZZZ and @canton7

Btw. It's my first post in this channel, should I mark it as "answered" or smth like that?

canton7•7/29/24, 3:16 PM

$close

Ccanton7 $close

MODiX•7/29/24, 3:16 PM

If you have no further questions, please use /close to mark the forum thread as answered

canton7•7/29/24, 3:16 PM

Not sure I understood you, as I mean typing instead of object sender, TextBox sender (or smth like that).

Happy to clarify, but I'm afraid I'm not sure what your confusion is

TomOP•7/29/24, 3:32 PM

@canton7 You've written:

Obviously if you subscribe to TextBox.TextChanged you expect the sender parameter to be an instance of TextChanged. You're not going to get some other control raising that event and inserting itself as the sender parameter.
But sometimes you have a list of 20 textboxes, and you want to do something when the text changes in any of them, and you don't want to define 20 handlers. So you define a single handler, and you use that sender parameter to interact with the specific textbox which raised the event

I've assumed that you meant using instead of e.g. make that (interaction without having 20 handlers) possible. I thought the latter makes it possible too (and the type in handler parameter precise kind of sender you are dealing with).

canton7•7/29/24, 3:57 PM

Oops, * Obviously if you subscribe to TextBox.TextChanged you expect the sender parameter to be an instance of TextBox.

canton7•7/29/24, 3:58 PM

My point was that there's no harm casting the to , since you know that it will always be an instance of

canton7•7/29/24, 6:50 PM

Hmm, no, I can't spot it

TomOP•7/29/24, 9:18 PM

Thanks, now I get your point. I think I'll try to use strongly typed param in handler definition, unless some framework force me to use . But I may of course change my opinion after having some more practice

Good talk, thank you, I'm closing the topic now. See you!