要做一体化自动化测试框架，那么，最重要的是要解决什么呢?相信了解windows编程的人员，都能发现这个问题所在。在窗体中，写下代码，控制每一个控件的输入是非常简单的事。但是，一旦显示了一个模态窗体，原有的流程代码会不再往下执行，而是停留在新窗体中，等待消息相应。这就是我们代码控制界面的关键问题。

　　 前面讲到要做一体化自动化测试框架，那么，最重要的是要解决什么呢?

　　 相信了解windows编程的人员，都能发现这个问题所在。在窗体中，写下代码，控制每一个控件的输入是非常简单的事。但是，一旦显示了一个模态窗体，原有的流程代码会不再往下执行，而是停留在新窗体中，等待消息相应。这就是我们代码控制界面的关键问题。

　　 这是什么道理呢?

 我使用的是delphi系统，所以我可能使用vcl框架来解释这个问题。但是其他语言同样适用。

 在windows程序中，winmain是入口。而winmain的处理，就是一个典型的死循环，先从消息队列中取出消息，然后再给各窗体派发消息。

　　 为了方便理解，我们将这个模型简化，就是一个死循环a。中间在处理任意的代码。

　　 现在，由于调用了某一段处理，进入了另外一个死循环b。当代码从a函数进入了b，那么当然，a循环下面的代码当然只能停留下来，直到b循环结束。

　　 而在windows界面中，模态窗体就是一个消息死循环。当windows弹出一个模态窗体的时候，其消息队列独立处理，不再走整个应用程序的消息循环。

　　 现在比较明白了，不能方便控制界面的原因在于windows应用程序并不是流程化的，而是消息驱动的。

　　 明白了这个道理，就有可能找到突破口。我想到了钩子。在delphi中使用钩子，推荐使用fastcode。

　　 既然程序从a循环进入到b循环，我不能继续执行a循环的代码，那么，可不可以在进入b循环后，继续执行a的代码呢?

　　 这应该是可行的。关键在于我必须做到b循环中，能够调用到我的代码。

 在 delphi的一般窗体，你可以通过使钩子hook住tform的doshow方法。那样，窗体不管是否是showmodal的，都会触发，然后通过给此 窗体发送一个特殊消息，并在此窗体中，使用钩子，处理此消息。那么就可以在窗体完全显示之后，真正处理你的任务了。这里有一个技巧，窗体真正显示，并不是 调用doshow的时候，而是经过windows的消息循环，完全处理好所有显示相关消息之后。这里，通过消息循环机制，给它发送一个额外消息，那么可以保障，触发你的任务的时机，是在窗体处理完原有消息之后。

　　 当然了，在vcl中，并不是这么简单就能处理所有问题。最主要的是那些标准windows窗体，比如messagebox，opendialog。这些窗体不是由tform组合而成的。所以对象和消息机制都不一样。需要单独处理。

　　 这里有一种方式，是通过定时器，定时查询活动窗体状态。如果检测到非标准windows窗体，手动触发你的任务。也是一种权衡解决方式。

　　 由于代码版权问题，我这里不能贴出这些代码，不过主要意思应该都讲清楚了吧。

　　 总结以下这个关键点：

　　 消息机制和流程代码的冲突，是根本原因

　　 简单的模型，就是循环嵌套循环问题

　　 使用钩子，在循环开始处，触发任务

　　 这样，基本就可以控制界面了。