Delphi 消息机制引入的一个副作用
Delphi 在处理进程的消息时引入了一个隐藏的窗体Application ，借此进行消息的分发。这样的机制优美的处理了消息的分发和处置的问题。但是最近我发现这个机制也引入了一个副作用，会在某些情况下影响程序的界面交互行为。
我遇到的需求是需要在程序中实现单个实例，并且在第二个实例被启动的时候，首先将前一个实例置到最前，然后退出。按说这样的问题应该是比较典型的例子，但是这样的一个简单需求就受到了这个副作用的影响。
我的实现方式是这样的：第二个实例启动的时候，对前一实例发一个消息，要求它将自己置前，然后退出。至于前一个实例的句柄怎么取得，可以用FindWindows ，也可以用命名的FileMapping ，总之，第一个窗体就这样接到了将自己置前的命令。
怎么将这个窗体置到最前呢？众所周知，SetForegroundWindow 并不能真正将一个窗体置到最前，相反的，为了礼貌起见，它会让这个指定的窗体在任务栏里面闪动，吸引用户注意，但是它不会把这个窗体盖在Z-Order 的顶端。很有教养，但是我不喜欢，因为这不是我想要的。
于是我使用了这样一个方法将我要的窗体直接置到最前面：
SetWindowPos(hForm, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE or SWP_NOSIZE);
SetWindowPos(hForm, HWND_NOTOPMOST, 0, 0, 0, 0, SWP_NOMOVE or SWP_NOSIZE);
强行把窗体拖到Z-Order 的顶端，然后去掉它的TOPMOST 属性，这样就可以了。有点不够礼貌，不过要是礼貌有用的话，要警察做什么？
好了，前面说的内容似乎和我们的标题没太多关系，可是后面的麻烦都根源在这里。
我发现，当第一个实例被最小化时，第二个实例将它唤醒，将它的主窗体置到最前，然后窗体的“最小化”按钮失效了！这时窗体可以操作、可以最大化、可以关闭，却再也不能最小化了！
这是一个很郁闷的问题，一个不能最小化的窗体实在是很不友好的，我可以接受一个不礼貌的窗体，却不愿意接受一个这样不友好的家伙。
我发现问题原因的过程是这样的：
在进程中，主窗体的WM_SYSCOMMAND 消息是被传递给Application 类处理的，当CmdType 为SC_MINIMIZE的时候，Application 会调用Minimize 方法：
procedure TApplication.Minimize;
begin
if not IsIconic(FHandle) then
begin
NormalizeTopMosts;
SetActiveWindow(FHandle);
if (MainForm <> nil) and (ShowMainForm or MainForm.Visible)
and IsWindowEnabled(MainForm.Handle) then
begin
SetWindowPos(FHandle, MainForm.Handle, MainForm.Left, MainForm.Top,
MainForm.Width, 0, SWP_SHOWWINDOW);
DefWindowProc(FHandle, WM_SYSCOMMAND, SC_MINIMIZE, 0);
end else
ShowWinNoAnimate(FHandle, SW_MINIMIZE);
if Assigned(FOnMinimize) then FOnMinimize(Self);
end;
end;
注意这个IsIconic(FHandle)，它就是问题原因的冰山一角。IsIconic 是用来检测窗体是否处于最小化状态的API。我发现，第二实例将前一实例的主窗体置前之后，这个窗体最小化调用这个方法时，每次IsIconic(FHandle) 都是True。也就是说，Application 一直认为自己是最小化的。
于是问题就比较清楚了：我们在将主窗体强行置到最前的时候，Application 并没有恢复原状态。于是在Minimize 方法中主窗体就得不到最小化的命令了。
难怪在VC 开发的程序中不会有这样的问题！因为不存在Application 的这个因素。
于是我们只要将主窗体强行置前之前，首先将Application 恢复：
if IsIconic(Application.Handle) then
begin
DefWindowProc(Application.Handle, WM_SYSCOMMAND, SC_RESTORE, 0);
end;
这样就好了。
欢迎光临作者的个人主页：http://www.mrspace.net/