C# Windows窗体应用程序栏桌面大小调整

好的。就在你认为自己已经把一切都弄明白的时候，你还没有

我已经编写并测试了一个功能性appbar类。当我使用一个简单的Windows窗体来扩展和测试该类时，它在XP（SP 3，32位）和Windows 7（64位）中都可以正常工作。其他窗口是可访问的，它们都适当地最大化。然而，当我使用我的“复杂”Windows窗体（即它是一个应用程序）并从appbar类派生它时，桌面似乎将其“踢”出去。我的意思是，所有东西最初都会适当调整大小，但随后桌面会将自身大小调整回原来的大小。有时，在将表单置于appbar模式后，这种情况会很快发生；有时，当我在表单外部单击（例如打开浏览器）时，这种情况会发生；有时，当表单调用MessageBox时，这种情况会发生。我把所有的表单函数放在后台工作人员那里，他们认为这可能是个问题，但结果是一样的。我在下面贴了三张图片。第一个将应用程序显示为其初始WinForm。第二个显示appbar“正在运行”。最后一个显示appbar未“运行”。如果您在查看问题时遇到问题，请注意回收站。有什么想法吗

编辑： 我通过日志记录找到了这些电话。每次桌面调整到“正常”时，它们似乎都会触发。现在，我正在尝试查看“简单”版本中是否有类似的模式

• msg=0x6（WM_激活）hwnd=0x1e03ea wparam=0x0 lparam=0x0结果=0x0
• msg=0x1c（WM_ACTIVATEAPP）hwnd=0x1e03ea wparam=0x0 lparam=0x1a90结果=0x0
• msg=0x1a（WM_WININICHANGE）hwnd=0x1e03ea wparam=0x2f lparam=0x9fe048结果=0x0
• msg=0x1a（WM_WININICHANGE）hwnd=0x1e03ea wparam=0x18 lparam=0x9fe038结果=0x0

---

所以这是一场白费力气的追逐。如果我的最后一句话听起来很荒谬，那就是。虽然我仍然不能100%确定这个理论（请有人在您空闲时证明/反驳），但这两个不同的句柄来自（1）表单实例化和（2）加载表单时的实际句柄。我假设API遵循与QUERY_POS和SET_POS相同的概念，即它最初检查并分配有效句柄。然后，在显示表单之前，它会仔细检查句柄值
长话短说，验证加载事件中句柄值的一行代码解决了整个问题
编辑：

---

更好的是，HandleCreated事件是不可替代的。
参考上面的四条消息，我将其缩小到了最后两条。在简单的形式中，这些仅在appbar解除锁定时触发。如果能在四个小时前找到这些就好了，哈哈。这让人更困惑了。仅供参考，这是层次结构：表单->应用程序->应用程序。这在工作版本和非工作版本中都是相同的。我注意到在工作版本中，WinInChange从未显示，因为appbarHandle变量等于调用的hWnd参数。然而，在非功能版本中，这是不正确的。这里，应用程序句柄就是要发送的内容。唉，我通过将appbarHandle变量设置为protected internal（与private相反）并在应用程序构造函数中分配它来纠正这个问题，但问题仍然存在。吼叫声仍在搜索…在旁注上，如果你要记下这个，请告诉我为什么。我是新来的，所以这些信息是有建设性的。谢谢。这是我发现的。应用程序最初是从表单派生的（因为AppBar类仍在编写中）。当基类更改时，Application.Designer.cs中的某些内容显然不喜欢此更改。我创建了一个新的“应用程序”来测试这个理论，它的功能应该是正常的。不确定是什么导致派生类和基类具有单独的句柄，但这似乎解决了这个问题。