通过 eventargs 传回数据的问题或最佳实践？
我有一个非 GUI 类，它生成有关其正在执行的操作的事件（表单又使用这些事件向用户显示进度）。
其中一个事件是 AboutToDoSomethingDestructiveEvent。现在，我们希望表单在引发 AboutToDoSomethingDestructiveEvent 时向用户显示一个对话框，询问他们是否希望发生 SomethingDestructive。如果他们选择“否”，那么我们将在客户 EventArgs 上设置一个值，原始表单将读取该值，然后跳过执行 SomethingDestructive。
这是事件和 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 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这种方法非常好，.NET Framework 中甚至有一个类： 取消事件参数
The approach is so good there's even a class in the .NET Framework for this: CancelEventArgs
你的想法就是正确的做法。 Console.CancelKeyPress 事件本质上是相同的事情。
Console.CancelKeyPress
The way you are thinking is the proper way to do it. The Console.CancelKeyPress event is essentially the same thing.
Console.CancelKeyPress
这是一个正确的方法，只要您有自己的 EventArgs，它继承自 System.EventArgs。这很常见，我能想到的最好的例子是 PostSharp 中的 FlowBehavior。
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.