我们有一个在多显示器环境下运行的应用程序。 用户通常会将应用程序对话框展开以跨越多个mointors。
如果用户locking工作站，然后解锁它，我们的应用程序被告知resize。
我们的用户发现这种行为令人沮丧，因为他们然后花一些时间恢复以前的布局。
我们还不确定是否是请求resize或Windows的graphics驱动程序。 希望通过这个问题，会更清楚哪个部分是负责任的，
（文件）浏览器和Firefox等stream行应用程序在此设置中的行为方式相同。 仅复制：
Win+E ）
Win+L ）， 当工作站被locking然后解锁时，如何防止窗口大小调整？
我们是否需要检查（un）locking代码？
我们还没有意识到另一种机制吗？
在调整窗口大小之前，应用程序将从Windows获取WM_WINDOWPOSCHANGING消息。 您可以拦截该消息并更改参数，强制窗口保持放置状态。 您需要小心，因为当用户尝试移动窗口或调整窗口大小时，会得到相同的消息。 可能在最大化或最小化的时候。
编辑：您可以使用WTSRegisterSessionNotification函数来获取其他消息。 这些消息旨在用于快速用户切换，但锁定屏幕在Windows中作为系统会话实现。
类似的问题有一个答案，允许您在会话解锁后在.net应用程序中恢复窗口大小 。
有人问SuperUser本质上是相同的问题，但从用户的角度来看： 当我锁定我的工作站时，如何阻止大窗口调整大小？
我尝试了Leif引用的问题中给出的解决方案，发现SessionSwitchReason.SessionUnlock事件似乎在计算机被锁定之后而不是之前被触发。 这意味着窗口大小和位置已经被重置，所以调整大小失败。
因此，我必须在计算机被锁定之前找到另一种存储当前大小和位置的方法。 我唯一可以做的就是订阅ResizeEnd for Winforms应用程序，并更新“预锁”的大小和位置。
我还没有能够得到它的WPF应用程序的工作，因为WPF没有相当于ResizeEnd （或我还没有找到它）和订阅SizeChanged和LocationChanged不够好，因为这些被解雇当电脑被锁定以及覆盖的大小和位置。
最后，我不得不挂钩到Windows ExitSizeMove事件来保存当前的大小和位置。 如何进入这个事件的细节可以在这里找到：
private const int WM_EXITSIZEMOVE = 0x232; private void Window_Loaded(object sender, RoutedEventArgs e) { HwndSource source = HwndSource.FromHwnd(new WindowInteropHelper(this).Handle); source.AddHook(new HwndSourceHook(WndProc)); } private IntPtr WndProc(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled) { if (msg == WM_EXITSIZEMOVE) { // save location and size of window handled = true; } return IntPtr.Zero; }