Raising events

[Dave A]

I am developing a somewhat complex component at the moment and coincidently
I am also reading the Framework Design Guidelines book.

After reading the section about event raising I have re-written the way my
component raises events to follow the Framework Design Guides verbatim; ie
(object sender, EventArgs (or some subclass there of) e).

The thing that was not explained is why should I need to cast the sender to
'object' when I know very well that it will be of type 'MyClass' or a
subclass there of.

By setting it to 'object' it makes more difficult for the consumer of the
event since they need to explicitly cast it to MyClass to do anything useful
with it.

If I were to declare the delegate as (MyClass sender, ...) then the consumer
would only need to explicitly cast it when they were dealing with a subclass
of MyClass.

By setting it to 'object' are we taking framework design guidelines just a
bit too far? Or is there some other benefit that I do not appreciate.

PS Pages 132 - 138, particular P138 (second 'do')

Thanks
Dave A

 

[Karl Seguin]

I *think* it's more to keep eventhandlers reusable. If this doesn't apply
in your case, I'd use the specific class type - I have in the past.

Karl

 

[Mahesh Devjibhai Dhola [MVP]]

Hi,
Microsoft event framework is such because many events have the same delegate like Click and GotFocus and some other has EventHandler is as a delegate also both event can be fired by any Button, or other lots of controls so it needs to be there "object" which can give you facility to use it with multiple events as well as multiple type of Control objects.

But if its not in your case, means only single type of requirement is there and its for only one type of Class or Interface then you just create your own Delegate with your specific sender Type and its also not required to have EventArgs, just pass the parameters or a bundle of parameter as some object of some collection type.
It will definately work.

Sample according to publisher-subscriber scenario in Observer design pattern:

On publisher side:
Delegate:
public void delegate MyDelegate(MyType sender, MyParamCollection params);
Event in MyType:
public event MyDelegate MyEvent;
define some method for raising event like,
private void OnMyEvent() {
MyParamCollection coll = new MyParamCollection();
:
:
if(MyEvent !=null) {
MyEvent(this, coll);
}
}
and call this method at some point where you want to raise the specific event,

On subscriber side:
objMyType.MyEvent += MyDelegate(MyEventHandlerMethod);
private void MyEventHandlerMethod(MyType sender, MyParamCollection params) {
do something.....
}

HTH,

 

[Dave A]

Thank you. However I would like to argue your following point...

and its also not required to have EventArgs, just pass the parameters or a bundle of parameter as some object of some collection type. It will definately work.

I don't doubt that this will work - but as it is explained in the book if you do adopt the "object sender, subclass of EventArgs e" approach then you are effectively future proofing your design since any future addition to your "subclass of EventArgs" class will not break any compatibility with previous releases. Following your suggestion of "just pass the parameters or a bundle of parameter as some object of some collection type" may not provide as much flexibility for future designs.

The design pattern that you describe below contradicts the Framework Design Guidelines book.

Regards
Dave A

Hi,
Microsoft event framework is such because many events have the same delegate like Click and GotFocus and some other has EventHandler is as a delegate also both event can be fired by any Button, or other lots of controls so it needs to be there "object" which can give you facility to use it with multiple events as well as multiple type of Control objects.

But if its not in your case, means only single type of requirement is there and its for only one type of Class or Interface then you just create your own Delegate with your specific sender Type and its also not required to have EventArgs, just pass the parameters or a bundle of parameter as some object of some collection type.
It will definately work.

Sample according to publisher-subscriber scenario in Observer design pattern:

On publisher side:
Delegate:
public void delegate MyDelegate(MyType sender, MyParamCollection params);
Event in MyType:
public event MyDelegate MyEvent;
define some method for raising event like,
private void OnMyEvent() {
MyParamCollection coll = new MyParamCollection();
:
:
if(MyEvent !=null) {
MyEvent(this, coll);
}
}
and call this method at some point where you want to raise the specific event,

On subscriber side:
objMyType.MyEvent += MyDelegate(MyEventHandlerMethod);
private void MyEventHandlerMethod(MyType sender, MyParamCollection params) {
do something.....
}

HTH,

 

[Mahesh Devjibhai Dhola [MVP]]

Hi,
I dont know about the book you have mentioned but as i mentioned that sender object and subclass of EventArg is facilities provided in Microsoft Event framework BUT IN CASE YOU WANT and if its requirement of your problem solution then you can use your custom type instead of object sender and also same as with EventArgs.
I normally, uses the same framework with custom EventArgs which have my required parameters or collection of it.
And for future perspective, you may right but i dont see any reason that Microsoft disallow this custome usage feature in FUTURE product... then also yes, its definately preferrable to follow such framework.
Finally, its all depends of problem type and solution requirements.

HTH,

and its also not required to have EventArgs, just pass the parameters or a bundle of parameter as some object of some collection type. It will definately work.

I don't doubt that this will work - but as it is explained in the book if you do adopt the "object sender, subclass of EventArgs e" approach then you are effectively future proofing your design since any future addition to your "subclass of EventArgs" class will not break any compatibility with previous releases. Following your suggestion of "just pass the parameters or a bundle of parameter as some object of some collection type" may not provide as much flexibility for future designs.

The design pattern that you describe below contradicts the Framework Design Guidelines book.

Regards
Dave A

Hi,
Microsoft event framework is such because many events have the same delegate like Click and GotFocus and some other has EventHandler is as a delegate also both event can be fired by any Button, or other lots of controls so it needs to be there "object" which can give you facility to use it with multiple events as well as multiple type of Control objects.

But if its not in your case, means only single type of requirement is there and its for only one type of Class or Interface then you just create your own Delegate with your specific sender Type and its also not required to have EventArgs, just pass the parameters or a bundle of parameter as some object of some collection type.
It will definately work.

Sample according to publisher-subscriber scenario in Observer design pattern:

On publisher side:
Delegate:
public void delegate MyDelegate(MyType sender, MyParamCollection params);
Event in MyType:
public event MyDelegate MyEvent;
define some method for raising event like,
private void OnMyEvent() {
MyParamCollection coll = new MyParamCollection();
:
:
if(MyEvent !=null) {
MyEvent(this, coll);
}
}
and call this method at some point where you want to raise the specific event,

On subscriber side:
objMyType.MyEvent += MyDelegate(MyEventHandlerMethod);
private void MyEventHandlerMethod(MyType sender, MyParamCollection params) {
do something.....
}

HTH,