我有一个“ControlMonitor”类,用于监听表单上发生的事件.它的工作方式是,我将要监视的表单传递给该类的实例,然后该类遍历所有表单的控件并注册其“相关”事件.例如,如果控件是TextBox,我注册TextChanged.如果控件是ComboBox,我会同时注册SelectedIndexChanged和TextChanged,依此类推.通过这种方式,“ControlMonitor”实例能够报告用户在表单中执行的每个重要操作,并且对表单代码本身的干扰最小.

它适用于报告表单中的任何控件,但我还需要知道表单启动了哪些常见的对话框/消息框以及用户如何响应它们.我应该提到的是,这里更大的目标是自动化：我们希望最终得到一组可重复的步骤,这些步骤可以编写成在自动化工具中播放的内容.为此,仅知道用户点击“文件/打开”是不够的;我们还需要知道启动的OpenFileDialog的窗口标题,用户选择的路径和DialogResult. MessageBox调用也是如此;我们需要知道窗口标题和DialogResult.

常见的对话框似乎对事件的支持很少(FolderBrowserDialog显然根本没有任何事件),而且我甚至不确定在监听MessageBox调用的结果时从哪里开始.当然,我可以编写一个封装常见对话框和MessageBox调用的包装类,并将结果传递给“ControlMonitor”实例……但是程序的其余部分必须始终使用这个包装类,并且我的“ControlMonitor”类的目标是,您可以将其包含在项目中,并在其中一个表单上进行监听,而对原始代码的入侵最小.

在“ControlMonitor”课程中我能做些什么吗？我需要所有对话框/消息框的DialogResults和窗口标题,对于更复杂的对话框,如OpenFileDialog,我还需要知道用户选择的路径等.“ControlMonitor”类是它试图听的程序的编译部分to,所以它可以直接访问传递给它的Form对象.我离这儿很近;我可以监视95％的应用程序,因为它大部分只是表单上的控件……我只需要一种方法来监视对话框！

解决方法:

我知道它可能需要对您的应用程序进行相当大的更改,但是为什么不使用松散耦合的事件代理设计呢？它将为您提供更多关于如何处理事件的灵活性.

微软发布的The Composite UI Application Block有一个示例事件代理,但编写自己的代理并不多.这个想法的要点是你有一个*经纪人,你的控件发布事件.然后,任何其他类都可以订阅任何这些事件.这使得事件发布/订阅松散耦合并消除了不同控件之间的强依赖性.