为什么在按下 Alt 之前我的 AfxMessageBox invisible/hidden？
Why is my AfxMessageBox invisible/hidden until Alt is pressed?
我正在开发 MFC 应用程序。我有一个继承自 CWinApp 的 class，它试图在其 InitInstance 函数中打开一个 AfxMessageBox。
当调用 AfxMessageBox 函数时，没有消息框可见，但我听到 Windows 铃声。如果我按 Alt，将出现消息框。 为什么 AfxMessageBox 没有立即出现？
这个问题提到了一个类似的问题，但答案只涉及非 MFC 函数 MessageBox，而不是 AfxMessageBox 我正在使用的函数：
MFC MessageBox Not Showing at Top Of All Windows
更新 1
我正在研究一个最小的可重现示例，但这很棘手，因为这是封装不良的大型应用程序的一部分。
在我的应用程序中，对函数 ProcessShellCommand() 的调用似乎导致 AfxMessageBox 停止工作。但是，在新创建的 MFC 应用程序中，对 AfxMessageBox 的调用在 ProcessShellCommand 之前和之后都能正常工作。
看起来调用 ProcessShellCommand 的某些结果导致 AfxMessageBox 行为不同，但我不确定如何识别调用 ProcessShellCommand 的所有结果。当我调试时，对 ProcessShellCommand 的特定调用包含一个文件名，因此文件打开命令导致应用程序的 CView 启动。
在我的 CView 继承 class 的 OnInitialUpdate 代码中，AfxMessageBox 功能正常。我可以确定 AfxMessageBox 工作和不工作之间的最佳过渡点是 CView 的 OnInitialUpdate 函数 returns 被 ProcessShellCommand 调用时.
更新 2
似乎 m_pMainWnd 在调用 ProcessShellCommand 之前是 NULL（而 AfxMessageBox 按预期工作），而在调用 NULL 之后是非 NULL调用 ProcessShellCommand.
基于这个讨论：
，我尝试打印出调用 ProcessShellCommand 之前和之后的消息队列内容。以前，消息队列只包含一条消息。之后，消息队列打印输出循环充满了 WM_PAINT，直到我按下 Alt，它才终止。这让我觉得我 运行 陷入了与消息泵相关的问题，而不是与例如相关的问题。可见性状态。
------------更多观察------------
看起来对 AfxMessageBox 的调用在 win32u.dll 中停止了；我通过在等待消息框出现时点击 'pause execution' 按钮来确定这一点。这是调用堆栈和调试屏幕截图：
原来我的 CWinApp 有一个 CFrameWnd class 我忘记了；我太关注 CView class.
在CFrameWndclass中，在BEGIN_MESSAGE_MAP块中，有一个ON_WM_TIMER()。我从消息映射中删除了它以进行测试，并且 AfxMessageBox() 按预期工作。
当我创建一个新的 SDI 应用程序时，消息映射块中没有 ON_WM_PAINT()，因此我认为这可能添加不正确。 class 本身没有实现 OnPaint()，所以我猜这导致一些未处理的 WM_PAINT 消息四处飘荡。
令人惊讶的是，这并没有导致编译器错误；据我了解，只有 ON_WM_PAINT() 具有相应的 OnPaint() 函数才有意义。
我正在开发 MFC 应用程序。我有一个继承自 CWinApp 的 class，它试图在其 InitInstance 函数中打开一个 AfxMessageBox。
当调用 AfxMessageBox 函数时，没有消息框可见，但我听到 Windows 铃声。如果我按 Alt，将出现消息框。 为什么 AfxMessageBox 没有立即出现？
这个问题提到了一个类似的问题，但答案只涉及非 MFC 函数 MessageBox，而不是 AfxMessageBox 我正在使用的函数：
MFC MessageBox Not Showing at Top Of All Windows
更新 1
我正在研究一个最小的可重现示例，但这很棘手，因为这是封装不良的大型应用程序的一部分。
在我的应用程序中，对函数 ProcessShellCommand() 的调用似乎导致 AfxMessageBox 停止工作。但是，在新创建的 MFC 应用程序中，对 AfxMessageBox 的调用在 ProcessShellCommand 之前和之后都能正常工作。
看起来调用 ProcessShellCommand 的某些结果导致 AfxMessageBox 行为不同，但我不确定如何识别调用 ProcessShellCommand 的所有结果。当我调试时，对 ProcessShellCommand 的特定调用包含一个文件名，因此文件打开命令导致应用程序的 CView 启动。
在我的 CView 继承 class 的 OnInitialUpdate 代码中，AfxMessageBox 功能正常。我可以确定 AfxMessageBox 工作和不工作之间的最佳过渡点是 CView 的 OnInitialUpdate 函数 returns 被 ProcessShellCommand 调用时.
更新 2
似乎 m_pMainWnd 在调用 ProcessShellCommand 之前是 NULL（而 AfxMessageBox 按预期工作），而在调用 NULL 之后是非 NULL调用 ProcessShellCommand.
基于这个讨论：
ProcessShellCommand 之前和之后的消息队列内容。以前，消息队列只包含一条消息。之后，消息队列打印输出循环充满了 WM_PAINT，直到我按下 Alt，它才终止。这让我觉得我 运行 陷入了与消息泵相关的问题，而不是与例如相关的问题。可见性状态。
------------更多观察------------
看起来对 AfxMessageBox 的调用在 win32u.dll 中停止了；我通过在等待消息框出现时点击 'pause execution' 按钮来确定这一点。这是调用堆栈和调试屏幕截图：
原来我的 CWinApp 有一个 CFrameWnd class 我忘记了；我太关注 CView class.
在CFrameWndclass中，在BEGIN_MESSAGE_MAP块中，有一个ON_WM_TIMER()。我从消息映射中删除了它以进行测试，并且 AfxMessageBox() 按预期工作。
当我创建一个新的 SDI 应用程序时，消息映射块中没有 ON_WM_PAINT()，因此我认为这可能添加不正确。 class 本身没有实现 OnPaint()，所以我猜这导致一些未处理的 WM_PAINT 消息四处飘荡。
令人惊讶的是，这并没有导致编译器错误；据我了解，只有 ON_WM_PAINT() 具有相应的 OnPaint() 函数才有意义。