views:

72

answers:

3

I've got a non-GUI class that generates events as to what it is doing (which are in turn used by a Form to display to the user the progress). One of the events is a AboutToDoSomethingDestructiveEvent. Now we want to have the Form display a dialog to the user when AboutToDoSomethingDestructiveEvent is raised, asking them if they would like SomethingDestructive to happen. If they select no, then we would set a value on the customer EventArgs and the original form would read that value and then skip doing SomethingDestructive.

Is this a proper use of Events and EventArgs? Are there problems with this approach? Are there any best practices for doing this sort of thing?

+1  A: 

The way you are thinking is the proper way to do it. The Console.CancelKeyPress event is essentially the same thing.

Console.CancelKeyPress

ChaosPandion
+1  A: 

This is a proper approach, as long as you have your own EventArgs, which are inheriting from System.EventArgs. It is very common, the best example I can think of is in PostSharp with the FlowBehavior.

Yuriy Faktorovich
+3  A: 

The approach is so good there's even a class in the .NET Framework for this: CancelEventArgs

dtb
Yup. Creating your own `EventArgs` which extends `CancelEventArgs` would be a very good solution here I think :)
Svish