我可以做什么最大化，风格的窗口，显示他们的边界在相邻的显示器
问题说明
在多监视器系统上，空白VCL应用程序可以最大限度地发挥最佳效果，但启用样式（默认情况下选择一种）的相同应用程序最大化不正确。我看到的是窗口的右边缘延伸到第二个监视器上（我的主要位于左侧）。当我开始与其他Windows应用程序进行比较时，我注意到在Windows 7（至少）下，最大化的窗口甚至在左边，右边和底部都没有非客户端边框。实际上，标准的VCL（非风格）应用程序的行为方式相同，没有非客户端边框。
On a multi-monitor system, a "blank" VCL application maximizes fine, but the same application with styles enabled (and one chosen as default) maximizes incorrectly. What I'm seeing is the right-hand edge of the window extend onto the 2nd monitor (my main is on the left). When I started comparing to other Windows apps, I noticed that under Windows 7 (at least), maximized windows do not even have non-client borders on the left, right or bottom sides. And indeed, the standard VCL (non-styled) app behaves this same way, without non-client borders.
我如何解决这个问题？我注意到TFormStyleHook有一个WMNCCalcSize的处理程序，我还没有解析，但是让我想知道VCL是否可能不正确地处理这个消息的最大化窗口。
How do I fix this? I notice that TFormStyleHook has a handler for WMNCCalcSize, which I haven't dissected yet, but makes me wonder if VCL might be incorrectly handling this message for a maximized window.
正确答案
在这段时间后，我的采取是，这不是一个vcl风格的bug。这确实与文章在评论中提到/ mghie> mghie 。
After fiddling some time on this, my take is, this is not a vcl-styles bug at all. This indeed is related with the behavior in the article mentioned in a comment to the question by mghie.
具体行为是，最大化窗口的大小大于窗口的显示器的工作区域最大化。假设窗口管理员隐藏了悬垂边界。显然，它并不完全用定制框架。请注意，MSDN自己的自定义窗口框架示例似乎也遇到同样的问题（请参阅社区内容中的窗口最大化时出现的标题为em的错误）。 VCL的应用程序与MSDN示例不同，因为它不是基于DWM，但我仍然认为这是同样的问题。
The specific behavior is that, the size of a maximized window is larger than the work area of the monitor that the window is maximized on. Supposedly, the window manager hides the overhang borders. Apparently, it doesn't quite do so with customized frames. Note that MSDN's own custom window frame example seems to suffer from the same problem (refer to the post titled "Bug when window is Maximized " in community content). VCL's application is different than the MSDN example in that it's not based on DWM, but I still think it is the same issue.
悬垂边框具有系统的大小尺寸边框（SM_C [X | Y] SIZEFRAME），但这与下面的解决方法无关，因为它忽略了操作系统建议的大小/位置并使用了工作区域。
The overhang borders have the size of the system sizing border (SM_C[X|Y]SIZEFRAME), but this is irrelevant to the workaround below as it disregards the OS suggested size/position and uses the work area.
不幸的是，我不认为这种解决方法是可用的。一方面，上述行为没有记录，二是解决办法不完善;还有一个奇怪的像素出来。如果您将窗口完全按在工作区域上，则窗口管理器决定将窗口偏移到它认为应该放置窗口（隐藏框架）的位置。 （VCL可能被修改为做窗口管理器所做的工作，并考虑到悬而未决，不绘制它们或类似的东西，但这将是更多的工作，它仍然是解决方法的无证行为..）
Unfortunately I don't think this workaround is usable at all. For one, the mentioned behavior is not documented, for two, the workaround is not perfect; there's still an odd pixel out. If you snap the window exactly on the work area, the window manager decides to offset the window to where it thinks the window (with hidden frames) should be placed. (The VCL could probably be modified to do what the window manager does, and take into account overhang and do not draw them or something similar, but it would be more work and it still would be to workaround undocumented behavior..)
无论如何;
type
TForm1 = class(TForm)
..
protected
// overriding styles is not necessary since TFormStyleHook.WMGetMinMaxInfo
// first calls the default window procedure
procedure WMGetMinMaxInfo(var Message: TWMGetMinMaxInfo);
message WM_GETMINMAXINFO;
..
procedure TForm1.WMGetMinMaxInfo(var Message: TWMGetMinMaxInfo);
var
R: TRect;
begin
// always arrives with MinMaxInfo.ptMaxPosition = (-SM_CXFRAME, -SM_CYFRAME)
// and MinMaxInfo.ptMaxSize = (PrimaryMonitor.Width (?) 2 * SM_CXFRAME, ... )
inherited;
// should test for OS, styles etc. before running the below
R := Monitor.WorkareaRect;
InflateRect(R, -1, -1); // odd pixel
OffsetRect(R, -Monitor.Left, -Monitor.Top);
Message.MinMaxInfo.ptMaxPosition := R.TopLeft;
Message.MinMaxInfo.ptMaxSize := Point(R.Width, R.Height);
end;
这篇好文章是转载于：学新通技术网
