当前位置：文江博客话题详情

当对话框失效时如何调试/跟踪？

发布于 2024-08-14 20:52:43 字数 214 浏览 4 评论 0原文

我的 MFC 应用程序有一个 CView 和几个浮动非模式对话框。我目前正在尝试弄清楚为什么我的视图的失效/重画也会导致对话框被重新绘制。如果对话框不与视图重叠，甚至会发生这种情况。

有人知道如何调试/跟踪谁请求特定的对话框重画吗？拦截对话框上的 WM_PAINT 消息似乎为时已晚。

预先感谢您的任何帮助！

最美好的祝愿，

法比安

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

压抑⊿情绪 2024-08-21 20:52:43

我认为您的非模式对话框是 WS_POPUP 窗口，对吗？（即它们是浮动窗口，可以出现在屏幕上的任何位置，而不仅仅是出现在应用程序窗口内。）。

如果它们是浮动窗口，那么从技术上讲，它们不是框架窗口的子窗口，但文档倾向于在真正应该使用“所有者”的地方使用术语“父级”，因此这很容易让人困惑。子窗口不能出现在其父窗口的客户区之外，拥有的窗口可以。当父窗口失效时，子窗口也将失效。但拥有的窗口则不会。

只有具有 WS_CHILD 样式标志的窗口才能是子窗口，否则它们是拥有的窗口。

如果这些是自有窗口，它们不会从主应用程序窗口继承失效，因此您需要在代码中查找以 NULL 句柄作为第一个参数调用 ::InvalidateRect() 的位置。通常这是由于未初始化的变量造成的。

当您调用 ::InvalidateRect(NULL, ...) 时，这会告诉 Windows 使所有窗口无效。（它实际上告诉 Windows 使桌面窗口无效，桌面窗口是所有窗口的父窗口）。对于 MFC，所有窗口的基类都有一个 InvalidateRect 方法，该方法反过来调用 Windows api，但使用当前对象的窗口句柄。作为一阶近似，我认为您可以假设该窗口句柄将被正确初始化。您应该首先在自己的代码中查找调用。

一旦获得 OnPaint，就无法知道失效请求来自哪里了。因此，为了找到这个错误，您必须检查代码或拦截 InvalidateRect() 并在第一个参数中查找 NULL。

在一般情况下，这是一个难题，因为有多种方法可以使整个或部分窗口无效，并且头文件中的大量代码可以通过创建此函数的变体来自动执行某些操作来“帮助”您。

您可以尝试在 InvalidateRect 顶部设置一个断点（位于 user32.dll 中），并以第一个参数为 null 为条件。但根据调试器的设置方式，您可能不被允许执行此操作。

您还可以尝试强制编译所有代码，以便通过您控制的函数重定向对 InvalidateRect 的调用。

// in some header file that gets included early by all of your code
#define InvalidateRect my_InvalidateRect

// in one of your .cpp files.
BOOL WINAPI my_InvalidateRect(HWND hwnd, CONST RECT *prc, BOOL bErase)
{
  #undef InvalidateRect
  assert(hwnd != NULL);
  InvalidateRect(hwnd, prc, bErase);
  #define InvalidateRect my_InvalidateRect
};

如果找不到，则对 InvalidateRgn 和 RedrawWindow 执行相同的操作，

这些类型的错误很难找到。我不羡慕你。在我自己的代码中，我永久禁止直接调用 InvalidateRect，它们必须始终通过包装函数，以便我始终可以在调试版本中检查 NULL 窗口句柄。但话又说回来，我不使用 MFC，因此执行此类策略更容易。

I presume that your non-modal dialogs are WS_POPUP windows, right? (i.e. they are floating windows that can appear anywhere on the screen, not just inside your app window.).

If they are floating windows then technically they aren't child windows of your frame window, but the documentation tends to use the term parent in places where it should really use owner so this is easy to get confused about. Child windows can't appear outside the client area of their parent, owned windows can. A child window will be invalidated whenever its parent window is invalidated. But an owned window will not.

Only windows with the WS_CHILD style flag can be child windows, otherwise they are owned windows.

If these are owned windows, they won't inherit invalidation from your main app window, so you need to look for places in your code where there is a call ::InvalidateRect() with a NULL handle as the first parameter. Usually this will be because of an uninitialized variable.

When you call ::InvalidateRect(NULL, ...) this tells Windows to invalidate ALL windows. (it actually tells Windows to invalidate the desktop window, which is the parent of all windows). With MFC, the base class for all windows has a method for InvalidateRect that turns around and calls the windows api but with the window handle of the current object. as a first order approximation, I think you can assume that THAT window handle will be initialized correctly. You should start by looking for calls in your own code.

Once you get the OnPaint, its too late to know where the invalidation request came from. So in order to find this bug, you are going to have to either inspect your code or intercept InvalidateRect() and look for NULL in the first param.

This is a HARD problem in the general case, because there are several ways to invalidate all or part of a window, and lots of code in header files to 'help' you by creating variants of this functions that do some things automatically.

You might try to set a breakpoint at the top of InvalidateRect (it's in user32.dll) and make that conditional on the first parameter being null. But depending on how your debugger is setup, you may not be allowed to do this.

You could also try and force all of your code to compile so that calls to InvalidateRect are redirected through a function that you control.

// in some header file that gets included early by all of your code
#define InvalidateRect my_InvalidateRect

// in one of your .cpp files.
BOOL WINAPI my_InvalidateRect(HWND hwnd, CONST RECT *prc, BOOL bErase)
{
  #undef InvalidateRect
  assert(hwnd != NULL);
  InvalidateRect(hwnd, prc, bErase);
  #define InvalidateRect my_InvalidateRect
};

If that doesn't find it, then do the same thing to InvalidateRgn and RedrawWindow

These kinds of bugs are nasty to find. I don't envy you. In my own code I have a permanent ban on direct calls to InvalidateRect, they must ALWAYS pass through a wrapper function so I can always check for NULL window handles in debug builds. But then again, I don't use MFC so enforcing this sort of policy is easier.

回复收藏 0 原文