2

好的。就在你认为你已经明白了一切的时候，你还没有。

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

在此处输入图像描述 在此处输入图像描述 在此处输入图像描述

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

  • msg=0x6 (WM_ACTIVATE) 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
4

1 回答 1

1

所以这是一场疯狂的追逐。如果我最后的评论听起来很荒谬，那就是。虽然我仍然不能 100% 确定这个理论（请有人在你闲暇时证明/反驳），但两个不同的句柄来自 (1) 表单的实例化和 (2) 加载表单时的实际句柄。我认为 API 遵循相同的 QUERY_POS 和 SET_POS 概念，即它最初检查并分配一个有效的句柄。然后，在显示表单之前，它会再次检查句柄值。

长话短说，在 Load 事件中验证句柄值的一行代码解决了整个问题。

编辑：更好的是，HandleCreated 事件是不可替代的。

于 2012-12-13T14:24:29.380 回答