Return values from __events

[Edward Diener]

I am gathering from the documentation that return values from __events are
not illegal but are frowned upon in .NET. If this is the case, does one pass
back values from an event handler via "in/out" or "out" parameters ? Or is
it simply that events are just notifications and are not interested in any
values which event handlers might be able to return ?

If the latter is the case, the event model in .NET appears to have a great
shortcoming. Let's say I have an event in a component which will normally be
occurring but which can be cancelled by a possible event handler before the
event occurs. This appears to me to be a common design idiom, which I have
used in my own non-.NET code. How does one handle this situation using
events in .NET ? I would much prefer my component's event notification to
possibly pick up this fact from some event handler and react accordingly,
but if events aren't supposed to pass back values, either via return values
or "in/out" | "out' values this idiom does not work.

[Daniel O'Connell]

Re: Return values from __events


"Edward Diener" <eddielee@tropi csoft.com> wrote in message
news:%23HTjSwdy DHA.1760@TK2MSF TNGP10.phx.gbl. ..[color=blue]
> I am gathering from the documentation that return values from __events are
> not illegal but are frowned upon in .NET. If this is the case, does one[/color]
pass[color=blue]
> back values from an event handler via "in/out" or "out" parameters ? Or is
> it simply that events are just notifications and are not interested in any
> values which event handlers might be able to return ?
>
> If the latter is the case, the event model in .NET appears to have a great
> shortcoming. Let's say I have an event in a component which will normally[/color]
be[color=blue]
> occurring but which can be cancelled by a possible event handler before[/color]
the[color=blue]
> event occurs. This appears to me to be a common design idiom, which I have
> used in my own non-.NET code. How does one handle this situation using
> events in .NET ? I would much prefer my component's event notification to
> possibly pick up this fact from some event handler and react accordingly,
> but if events aren't supposed to pass back values, either via return[/color]
values[color=blue]
> or "in/out" | "out' values this idiom does not work.[/color]

In most cases, you would use a member variable in the EventArgs derived
class you should be passing with the event notification. A proper event
delegate signature should be in the form name(object sender, EventArgs args)
You are pretty much free to do whatever you want in the EventArgs derived
parameter, some Framework code uses a Handled property on that class which
you can set, you could, in theory anyway, extend the class to provide a
mechanism to report back to the event server immediatly(even with another
event!), I can't say if it would be a good idea or not, but you are free to
do so.
[color=blue]
>
>[/color]

[Edward Diener]

Re: Return values from __events

Daniel O'Connell wrote:[color=blue]
> "Edward Diener" <eddielee@tropi csoft.com> wrote in message
> news:%23HTjSwdy DHA.1760@TK2MSF TNGP10.phx.gbl. ..[color=green]
>> I am gathering from the documentation that return values from
>> __events are not illegal but are frowned upon in .NET. If this is
>> the case, does one pass back values from an event handler via
>> "in/out" or "out" parameters ? Or is it simply that events are just
>> notifications and are not interested in any values which event
>> handlers might be able to return ?
>>
>> If the latter is the case, the event model in .NET appears to have a
>> great shortcoming. Let's say I have an event in a component which
>> will normally be occurring but which can be cancelled by a possible
>> event handler before the event occurs. This appears to me to be a
>> common design idiom, which I have used in my own non-.NET code. How
>> does one handle this situation using events in .NET ? I would much
>> prefer my component's event notification to possibly pick up this
>> fact from some event handler and react accordingly, but if events
>> aren't supposed to pass back values, either via return values or
>> "in/out" | "out' values this idiom does not work.[/color]
>
> In most cases, you would use a member variable in the EventArgs
> derived class you should be passing with the event notification. A
> proper event delegate signature should be in the form name(object
> sender, EventArgs args) You are pretty much free to do whatever you
> want in the EventArgs derived parameter, some Framework code uses a
> Handled property on that class which you can set, you could, in
> theory anyway, extend the class to provide a mechanism to report back
> to the event server immediatly(even with another event!), I can't say
> if it would be a good idea or not, but you are free to do so.[/color]

So essentially the suggested signature for an event is:

void MyEvent(System: :Object *,MyDerivedEven tArgs);

I assume that this is just a way of conforming to what the .NET framework
usually uses so that event handlers are used to handling events with this
type of signature, rather than something which is mandated.

I don't mind following it. However I have certain events where I will
manually be calling the event handlers in the delegate chain before the
event occurs and, if an event argument is set to false, it becomes a
notification back to me from the event handler that the event should not
take place, and I also stop calling the rest of the event handlers for that
event. This particular design pattern works well for something I am doing,
and it would be clearer in that case to simply have the __event be
prototyped as returning a 'bool' value for 'continue with the event or not'
than for me to add the 'bool' value to MyDerivedEventA rgs.

That is why I asked the original question. I do not see anything in the CLR
which does not allow a multi-cast event to have a return value. It does say
in the specs for __delegate, which of course __event uses, that the return
value for the delegate is the return value of the last handler, which of
course makes sense. However, in my design pattern for this type of event,
where I am calling the event handlers myself, it seems that I can check the
'bool' return value from each handler, and stop if one of them is 'false'.
Is there anything in the CLR or CLS which prevents this ? If so, I will add
my 'bool' return to MyDerivedEventA rgs but if not it is clearer to the event
handler if the 'bool' value is the return value for my event.

[Daniel O'Connell]

Re: Return values from __events


"Edward Diener" <eddielee@tropi csoft.com> wrote in message
news:e13MTZiyDH A.4064@tk2msftn gp13.phx.gbl...[color=blue]
> Daniel O'Connell wrote:[color=green]
> > "Edward Diener" <eddielee@tropi csoft.com> wrote in message
> > news:%23HTjSwdy DHA.1760@TK2MSF TNGP10.phx.gbl. ..[color=darkred]
> >> I am gathering from the documentation that return values from
> >> __events are not illegal but are frowned upon in .NET. If this is
> >> the case, does one pass back values from an event handler via
> >> "in/out" or "out" parameters ? Or is it simply that events are just
> >> notifications and are not interested in any values which event
> >> handlers might be able to return ?
> >>
> >> If the latter is the case, the event model in .NET appears to have a
> >> great shortcoming. Let's say I have an event in a component which
> >> will normally be occurring but which can be cancelled by a possible
> >> event handler before the event occurs. This appears to me to be a
> >> common design idiom, which I have used in my own non-.NET code. How
> >> does one handle this situation using events in .NET ? I would much
> >> prefer my component's event notification to possibly pick up this
> >> fact from some event handler and react accordingly, but if events
> >> aren't supposed to pass back values, either via return values or
> >> "in/out" | "out' values this idiom does not work.[/color]
> >
> > In most cases, you would use a member variable in the EventArgs
> > derived class you should be passing with the event notification. A
> > proper event delegate signature should be in the form name(object
> > sender, EventArgs args) You are pretty much free to do whatever you
> > want in the EventArgs derived parameter, some Framework code uses a
> > Handled property on that class which you can set, you could, in
> > theory anyway, extend the class to provide a mechanism to report back
> > to the event server immediatly(even with another event!), I can't say
> > if it would be a good idea or not, but you are free to do so.[/color]
>
> So essentially the suggested signature for an event is:
>
> void MyEvent(System: :Object *,MyDerivedEven tArgs);[/color]
Effectivly.[color=blue]
>
> I assume that this is just a way of conforming to what the .NET framework
> usually uses so that event handlers are used to handling events with this
> type of signature, rather than something which is mandated.
>
> I don't mind following it. However I have certain events where I will
> manually be calling the event handlers in the delegate chain before the
> event occurs and, if an event argument is set to false, it becomes a
> notification back to me from the event handler that the event should not
> take place, and I also stop calling the rest of the event handlers for[/color]
that[color=blue]
> event. This particular design pattern works well for something I am doing,
> and it would be clearer in that case to simply have the __event be
> prototyped as returning a 'bool' value for 'continue with the event or[/color]
not'[color=blue]
> than for me to add the 'bool' value to MyDerivedEventA rgs.
>
> That is why I asked the original question. I do not see anything in the[/color]
CLR[color=blue]
> which does not allow a multi-cast event to have a return value. It does[/color]
say[color=blue]
> in the specs for __delegate, which of course __event uses, that the return
> value for the delegate is the return value of the last handler, which of
> course makes sense. However, in my design pattern for this type of event,
> where I am calling the event handlers myself, it seems that I can check[/color]
the[color=blue]
> 'bool' return value from each handler, and stop if one of them is 'false'.
> Is there anything in the CLR or CLS which prevents this ? If so, I will[/color]
add[color=blue]
> my 'bool' return to MyDerivedEventA rgs but if not it is clearer to the[/color]
event[color=blue]
> handler if the 'bool' value is the return value for my event.[/color]

It is a pattern that should be followed when possible. Its often clearer to
users because most other events(if not all) follow it. I think FxCop will
complain about events not in that pattern as well.

While returning bool is clearer in a classic sense(C++ or a procedural
language for example), its not generally proper in the .NET strata, and may
not be as clear as it seems. People who have been using the framework for a
long time may be forced to double take due to the unexpected return value.
I've made the same mistake, with an out parameter, it turned out to not be
as straightforward to use as I figured it would be. I suggest sticking with
the existing pattern.
Anyway, to be clear, it should work at the CLR level. I don't know if it is
compliant with the CLS or not, but there is nothing I know of that will
block it from compiling. I do know its against class library guidelines, but
such a discussion is out of scope here. Reposting about that in
microsoft.publi c.dotnet.genera l would likely produce more varied and
interesting replies.

[Edward Diener]

Re: Return values from __events

Daniel O'Connell wrote:[color=blue]
> "Edward Diener" <eddielee@tropi csoft.com> wrote in message
> news:e13MTZiyDH A.4064@tk2msftn gp13.phx.gbl...[color=green]
>> Daniel O'Connell wrote:[color=darkred]
>>> "Edward Diener" <eddielee@tropi csoft.com> wrote in message
>>> news:%23HTjSwdy DHA.1760@TK2MSF TNGP10.phx.gbl. ..
>>>> I am gathering from the documentation that return values from
>>>> __events are not illegal but are frowned upon in .NET. If this is
>>>> the case, does one pass back values from an event handler via
>>>> "in/out" or "out" parameters ? Or is it simply that events are just
>>>> notifications and are not interested in any values which event
>>>> handlers might be able to return ?
>>>>
>>>> If the latter is the case, the event model in .NET appears to have
>>>> a great shortcoming. Let's say I have an event in a component which
>>>> will normally be occurring but which can be cancelled by a possible
>>>> event handler before the event occurs. This appears to me to be a
>>>> common design idiom, which I have used in my own non-.NET code. How
>>>> does one handle this situation using events in .NET ? I would much
>>>> prefer my component's event notification to possibly pick up this
>>>> fact from some event handler and react accordingly, but if events
>>>> aren't supposed to pass back values, either via return values or
>>>> "in/out" | "out' values this idiom does not work.
>>>
>>> In most cases, you would use a member variable in the EventArgs
>>> derived class you should be passing with the event notification. A
>>> proper event delegate signature should be in the form name(object
>>> sender, EventArgs args) You are pretty much free to do whatever you
>>> want in the EventArgs derived parameter, some Framework code uses a
>>> Handled property on that class which you can set, you could, in
>>> theory anyway, extend the class to provide a mechanism to report
>>> back to the event server immediatly(even with another event!), I
>>> can't say if it would be a good idea or not, but you are free to do
>>> so.[/color]
>>
>> So essentially the suggested signature for an event is:
>>
>> void MyEvent(System: :Object *,MyDerivedEven tArgs);[/color]
> Effectivly.[color=green]
>>
>> I assume that this is just a way of conforming to what the .NET
>> framework usually uses so that event handlers are used to handling
>> events with this type of signature, rather than something which is
>> mandated.
>>
>> I don't mind following it. However I have certain events where I will
>> manually be calling the event handlers in the delegate chain before
>> the event occurs and, if an event argument is set to false, it
>> becomes a notification back to me from the event handler that the
>> event should not take place, and I also stop calling the rest of the
>> event handlers for that event. This particular design pattern works
>> well for something I am doing, and it would be clearer in that case
>> to simply have the __event be prototyped as returning a 'bool' value
>> for 'continue with the event or not' than for me to add the 'bool'
>> value to MyDerivedEventA rgs.
>>
>> That is why I asked the original question. I do not see anything in
>> the CLR which does not allow a multi-cast event to have a return
>> value. It does say in the specs for __delegate, which of course
>> __event uses, that the return value for the delegate is the return
>> value of the last handler, which of course makes sense. However, in
>> my design pattern for this type of event, where I am calling the
>> event handlers myself, it seems that I can check the 'bool' return
>> value from each handler, and stop if one of them is 'false'. Is
>> there anything in the CLR or CLS which prevents this ? If so, I will
>> add my 'bool' return to MyDerivedEventA rgs but if not it is clearer
>> to the event handler if the 'bool' value is the return value for my
>> event.[/color]
>
> It is a pattern that should be followed when possible. Its often
> clearer to users because most other events(if not all) follow it. I
> think FxCop will complain about events not in that pattern as well.
>
> While returning bool is clearer in a classic sense(C++ or a procedural
> language for example), its not generally proper in the .NET strata,
> and may not be as clear as it seems. People who have been using the
> framework for a long time may be forced to double take due to the
> unexpected return value.[/color]

Yes, I can understand this. Yet a design pattern which allows an event
handler for an upcoming event to essentially cancel the event, by
'returning' a bool false value, seems not to have been in the consideration
of the .NET designers. In fact the general explanation for reacting to
events is that the event is just a notification and if the event handler
wants to do anything in regard to this event with the object generating the
event, it needs to access the object directly through the sender parameter.
This seems unnecessarily complicated to me. The idea that an event handler
should never affect the event itself through the event handler parameters
seems too simplistic. Of course there is nothing stopping me from designing
my own events. But I really wish that some of the discussions regarding
events in the MSDN doc had acknowledged the fact that event handlers might
want to cancel or alter the event itself.
[color=blue]
> I've made the same mistake, with an out
> parameter, it turned out to not be as straightforward to use as I
> figured it would be. I suggest sticking with the existing pattern.
> Anyway, to be clear, it should work at the CLR level. I don't know if
> it is compliant with the CLS or not, but there is nothing I know of
> that will block it from compiling. I do know its against class
> library guidelines, but such a discussion is out of scope here.
> Reposting about that in microsoft.publi c.dotnet.genera l would likely
> produce more varied and interesting replies.[/color]

Thanks for your reply. I will probably follow the standard guidelines even
if it goes against my sense of design in this case. I have looked at the CLS
specification and there is nothing there which specifies anything about the
types in the method signature for an event other than that the types
themselves must be CLS compliant. Neverthless, who am I to upset the status
quo <g> . Actually the guidelines are decent as having a structure to pass
event arguments is simpler than having a series of parameters, if less
understandable in general.

[Daniel O'Connell]

Re: Return values from __events

<snip>[color=blue]
> Yes, I can understand this. Yet a design pattern which allows an event
> handler for an upcoming event to essentially cancel the event, by
> 'returning' a bool false value, seems not to have been in the[/color]
consideration[color=blue]
> of the .NET designers. In fact the general explanation for reacting to
> events is that the event is just a notification and if the event handler
> wants to do anything in regard to this event with the object generating[/color]
the[color=blue]
> event, it needs to access the object directly through the sender[/color]
parameter.[color=blue]
> This seems unnecessarily complicated to me. The idea that an event handler
> should never affect the event itself through the event handler parameters
> seems too simplistic. Of course there is nothing stopping me from[/color]
designing[color=blue]
> my own events. But I really wish that some of the discussions regarding
> events in the MSDN doc had acknowledged the fact that event handlers might
> want to cancel or alter the event itself.
>[/color]
There is no particular discussion I know of, something like [1] is the model
I'd use. Also, by allowing all your event properties to be settable, ideally
a event handler could modify the event data easily. However, you should look
into event ordering. As far as I know, there is no guarentee that an event
will be called in any predictable order, without that a handler that changes
events may end up being called last. Unless there is a guarentee its
something I'd be hesitant to rely on.
[color=blue][color=green]
> > I've made the same mistake, with an out
> > parameter, it turned out to not be as straightforward to use as I
> > figured it would be. I suggest sticking with the existing pattern.
> > Anyway, to be clear, it should work at the CLR level. I don't know if
> > it is compliant with the CLS or not, but there is nothing I know of
> > that will block it from compiling. I do know its against class
> > library guidelines, but such a discussion is out of scope here.
> > Reposting about that in microsoft.publi c.dotnet.genera l would likely
> > produce more varied and interesting replies.[/color]
>
> Thanks for your reply. I will probably follow the standard guidelines even
> if it goes against my sense of design in this case. I have looked at the[/color]
CLS[color=blue]
> specification and there is nothing there which specifies anything about[/color]
the[color=blue]
> types in the method signature for an event other than that the types
> themselves must be CLS compliant. Neverthless, who am I to upset the[/color]
status[color=blue]
> quo <g> . Actually the guidelines are decent as having a structure to pass
> event arguments is simpler than having a series of parameters, if less
> understandable in general.[/color]
Yeah, its a little strange, but allows for proper OO behaviour. You don't
have to pass a concrete derived event args, but you could possibly pass an
extended one that handlers can test for, etc. Its not always advisable, but
it is possible.[color=blue]
>
>[/color]