Problems with, or best practices for, passing data back through eventargs?

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 lik开发者_运维问答e 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?

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

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

Console.CancelKeyPress

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.