CancelEventArgs.Cancel - How Event Raising Code Know if Client Set .Cancel=true

[Smithers]

In consideration of the brief sample code at the following link...

http://msdn2.microsoft.com/en-us/library/system.componentmodel.canceleventargs.cancel.aspx

.... when we set e.Cancel = true, How does the form subsequently know to NOT
close the form? More generally, after an event is raised, does the event
raising class somehow retain a reference to the CancelEventArgs instance,
and then check the value of the .Cancel property to subsequently know if
further processing (e.g., actually close the form) is to be aborted? Is it
that simple?

The upshot here is that I'm looking into providing a cancellable events -
and I was wondering how I might make use of CancelEventArgs.Cancel. My plan
is to derive a new "event args" class from CancelEventArgs, and let the
client set the .Cancel property - just like we can set that property for the
FormClosing event.


Thanks!

 

[Peter Duniho]

In consideration of the brief sample code at the following link...

http://msdn2.microsoft.com/en-us/library/system.componentmodel.canceleventargs.cancel.aspx

.... when we set e.Cancel = true, How does the form subsequently know to NOT
close the form? More generally, after an event is raised, does the event
raising class somehow retain a reference to the CancelEventArgs instance,
and then check the value of the .Cancel property to subsequently know if
further processing (e.g., actually close the form) is to be aborted? Is it
that simple?

Yes, I believe it is. Note that there's no magic to "somehow retaining
a reference". The code that instantiates the CancelEventArgs instance
is likely the same code that calls OnFormClosing to raise the event. So
all it would have to do is wait for the call to OnFormClosing to return
and then check the flag in the CancelEventArgs instance. The instance
is probably just referenced by a local variable, passed to OnFormClosing.

The upshot here is that I'm looking into providing a cancellable events -
and I was wondering how I might make use of CancelEventArgs.Cancel. My plan
is to derive a new "event args" class from CancelEventArgs, and let the
client set the .Cancel property - just like we can set that property for the
FormClosing event.

Sounds like a fine plan to me. Whatever code is actually instantiating
your args class would check the flag after calling the method that
raises the event, and the flag will be set if any of the code dealing
with the event sets it.

Pete

 

[Smithers]

Very good then. Tomorrow (well, later today, anyway), I'll write a small
sample and report back here on how it went.

-S

 

[Smithers]

Yes, I believe it is. Note that there's no magic to "somehow retaining a
reference".

Confirmed. Without thinking it through very well it just seemed like
something special might be going on, what with the delegate sitting between
the event publisher and subscribers --- you know what we hear, "the event
handler hides the subscribers from the publisher". That, plus I had some
presumption - don't ask why - that the event handler delegates were invoking
their referenced event handling methods asynchronously. Testing today
confirmed they aren't (news to me!). But I doubt even that would make a
difference at the end of the day (in terms of the publisher being able to
see 'e' (eventargs instance). That _would_ however make a difference in
terms of the timing involved in the publisher giving any/all subscribers a
chance to set the value of .Cancel, with the subscriber needing block until
any/all subscribers returned. But no concern as the calls are synchronous...

-S