使用正确的方法来监视创建句柄时要执行的任务吗？ [英] Am I using the right approach to monitor the tasks I want to perform when a handle is created?
问题描述
例如，我想到的第一件事是这样的： p>
// Foo.cs
// ...
Bar bar = new Bar / * add'l req'd state * /）;
EventHandler handler = new EventHandler（bar.HandlerMethod）;
bar.HandlerToUnsubscribe = handler;
eventSource.EventName + = handler;
// ...
// Bar.cs
class Bar
{
/ * add'l req'd state * /
// .ctor
public EventHandler HandlerToUnsubscribe {get;组;
public void HandlerMethod（object sender，EventArgs args）
{
//做什么必须完成w / add'l req'd状态
（（ EventSourceType）sender）.EventName - = this.HandlerToUnsubscribe;
}
}
说这个感觉是黑客/坏是一个低调。它与时间依赖紧密耦合（ HandlerToUnsubscribe 必须在正确的时间分配确切的值）。在这种情况下，我觉得我一定是玩复杂的一部分 - 有没有什么愚蠢或简单的我失踪了？
上下文：
我在Winforms中使用UI和专有命令基础结构之间的绑定（使用System.Windows中有用的 ICommand 。输入）。绑定基础设施的一个方面是在UI命令组件（如工具栏按钮或菜单项）之间创建绑定的用户可以选择监听命令的 CanExecuteChanged 事件然后根据这一点更新UI的状态 - 通常将Enabled属性设置为 true 或 false 。
该技术通常工作得很好，但是有一些方法可以在ui组件的句柄被创建之前被触发。我试图保证提供的处理程序不会运行，除非已经创建了句柄。因此，我正在考虑提供一个有助于实现的一般助手类（ Bar ）。 Bar 的目标是检查是否存在适当的句柄。如果是的话，太棒了！如果没有，它将订阅适当的 IsHandleCreated 事件，以便在最终创建句柄时提供的处理程序运行。 （这是重要的b / c客户端可能会在UI的.ctor中设置它们的绑定，在句柄存在之前。）我希望这个订阅是完全透明的，然而，我也希望每个事件处理程序自动取消订阅 IsHandleCreated 一旦运行完毕。
我还在想一想，是一个好主意，所以我还没有概括这个概念 - 在这种情况下，我只是直接针对ToolStripItems来实现，以验证这个想法是否正确。我没有出售它，但是，
我明白，我也可以选择只需要在创建UI的句柄后才能创建绑定，在表单（例如）的OnLoad事件中。我知道这可以工作，我以前做过。在这种情况下，我想看看是否可以缓解该特定要求。
Greg，
你有什么不是观察者模式，而是消息队列。所以你只是使用错误的设计模式来解决你想要解决的问题。
它很简单，可以从头开始使用 Queue {Action {object}} ，其中对象排队自己，而您在调用它们时就会将项目排队。
Is there a generally-accepted best practice for creating an event handler that unsubscribes itself?
E.g., the first thing I came up with is something like:
// Foo.cs
// ...
Bar bar = new Bar(/* add'l req'd state */);
EventHandler handler = new EventHandler(bar.HandlerMethod);
bar.HandlerToUnsubscribe = handler;
eventSource.EventName += handler;
// ...
// Bar.cs
class Bar
{
/* add'l req'd state */
// .ctor
public EventHandler HandlerToUnsubscribe { get; set; }
public void HandlerMethod(object sender, EventArgs args)
{
// Do what must be done w/ add'l req'd state
((EventSourceType)sender).EventName -= this.HandlerToUnsubscribe;
}
}
To say that this feels hackish/bad is an understatement. It's tightly coupled with a temporal dependency (HandlerToUnsubscribe must be assigned the exact value at the exact right time). I feel like I must be playing the part of a complicator in this case--- is there something stupid or simple that I'm missing?
Context:
I'm creating a binding between the UI and a proprietary commanding infrastructure in Winforms (using the useful ICommand in System.Windows.Input). One aspect of the binding infrastructure is that users who create a binding between a UI command component (like a toolbar button or menu item) have the option to listen to the command's CanExecuteChanged event and then update the UI's state based on that-- typically setting the Enabled property to true or false.
The technique generally works quite well, but there are ways for the event to be fired prior to a ui component's handle having been created. I'm trying to guarantee that the provided handler isn't run unless the handle has been created. Resultantly, I'm considering providing a general helper class ("Bar") that will aid implementation. The goal of Bar is to check to see if the appropriate handle exists. If so, great! If not, it will subscribe to appropriate IsHandleCreated event so that the supplied handlers get run when the handle eventually is created. (This is important b/c the client may set their bindings in the UI's .ctor, before a handle exists.) I want this subscription to be completely transparent, however, and so I also want each event handler to automatically unsubscribe itself from IsHandleCreated once it's finished running.
I'm still at a point where I'm trying to figure out if this is a good idea, so I haven't generalized the concept yet-- I've only implemented it directly against ToolStripItems in this case to verify that the idea is sound. I'm not sold on it yet, though.
I understand that I also have the option of simply mandating that bindings can only be created once the UI's handle has been created, in the OnLoad event of a form (e.g.). I know that can work, I've done it in the past. I'd like to see if I can ease that particular requirement in this case though. If it's even practical.
Greg,
What you have is not an observer pattern, but rather a message queue. So you're just using the wrong design pattern for the problem you're trying to solve.
Its easy enough to implement your own message queue from scratch using a Queue{Action{object}}, where objects enqueue themselves, and you simply dequeue items as you invoke them.
这篇关于使用正确的方法来监视创建句柄时要执行的任务吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
