问题标签 [peekmessage]

我正在尝试在 .NET Windows 窗体应用程序的 C++/CLI 库中创建渲染循环，但 PeekMessage 从未收到任何消息。所以我的渲染循环是无限的，表格看起来冻结了。

我已经尝试了几种方法，但这是我最后一次尝试。

开始渲染循环：

处理它的代码：

因此，如果我没有做错任何事情，我会不断检查来自我的 Windows 句柄的消息（也尝试过使用 NULL），否则我会渲染东西。但是窗口被冻结了，因为我从来没有收到任何消息，IsAppIdle 总是返回 true。我无法聚焦窗口，调整它的大小或任何东西..

非常感谢您的帮助。

编辑 1： 如果我在每一帧中执行 Application::DoEvent() ，它就会起作用。但是性能缺点是什么？

编辑 2：

我现在很确定我的 PeekMessage 没有收到任何消息，因为 RenderLoop 在类库中，而不是直接在 WindowForm 中。PeekMessage 直接在表单代码中正常工作。这是正常的行为吗？也许 C# 在加载 CLI 程序集时会自动将其加载到另一个线程上？所以我的 PeekMessage 正在寻找错误的线程？

我有以下代码

SendApp，当点击按钮[X]时，执行以下代码

ReceiveApp，这只是一个接收SendApp消息的应用程序

如您所见，我想在 ReceiveApp 中增加变量 i 之前删除消息队列中的所有消息。我读了这篇文章，看到了

PM_REMOVE - PeekMessage 处理后从队列中删除消息。

我认为应该删除所有消息，但它们没有，在我按下 SendApp 中的按钮 [X] 后，ReceiveApp 中的变量 i 仍然增加 7。

那么如何删除消息队列中的所有消息？

我遇到了奇怪的问题。我有 C++ (WinAPI) 应用程序，如果我通过 [X] 窗口按钮关闭它，一切正常 - 窗口关闭，应用程序结束。

但是当我从任务栏按钮上下文菜单关闭应用程序时，窗口关闭但应用程序/进程仍在运行。卡在 GetMessage 上。

该应用程序仅包含一个窗口。

我的 WndProc 只包含 WM_DESTROY 处理程序，在任何情况下都可以正确处理：

应用程序的主循环是：

当我从任务栏菜单关闭应用程序时，窗口关闭但进程仍停留在 GetMessage 上。就像它没有正确接收 WM_QUIT 一样。但是如果我用 PeekMessage 替换 GetMessage，它会正确地从队列中读取 WM_QUIT。

此外，只需在 GetMessage 之前添加额外的 PeekMessage 即可：

从任务栏菜单关闭应用程序时，简单的 GetMessage 无法正确接收 WM_QUIT 有什么原因吗？

重现问题的最少应用程序代码：

我正在尝试为 MacOS 编写一个简单的游戏循环。我在 GLFW、SDL 和 MacOS 游戏端口等库中找到的用于 DOOM、Quake、Handmade Hero的事件轮询nextEventMatchingMask解决方案是使用API。我对事件轮询的延迟感兴趣：

我运行的实验（源代码）包括打开一个 Cocoa MacOS 窗口和“随机”生成鼠标和键盘事件。我在此类实验中获得的前 1000 个事件的典型延迟数如下所示

请注意，前 25% 的延迟超过半毫秒。即使没有可用的事件（图表上的零），我们也可以获得超过一毫秒的延迟（参见第 600 个事件附近浮动的零）。更糟糕的是，这是我在 Macbook 没有太多工作时观察到的典型情况：只有一个终端和测试程序。当更多应用程序运行时，情况会变得更糟。

我想知道如果在 MacOS 应用程序中可用，是否有更有效的方法来获取下一个（鼠标/键盘）事件。我是否缺少使nextEventMatchingMask通话更高效的技巧？

可以在此处找到运行此测试并生成类似上述图的源代码：https ://github.com/laurolins/cocoa_poll_events_latency

（更新）按照爸爸在评论中提出的想法，我在没有任何鼠标/键盘移动的情况下进行了测试。以下是延迟百分位数：

等待 0.15 毫秒以发现没有生成事件的想法感觉不对！

（更新 2）刚刚对在 ubuntu 上运行的gzdoomSDL_EventPoll和MessagePump调用进行计时，我得到的延迟分布看起来好多了：

而在 MacOS 上，gzdoom 还与nextEventMatchingMask（数百微秒的延迟数）的缓慢作斗争。结论：在 MacOS 上获取下一个键盘/鼠标事件的速度不仅是我的测试代码。

我正在用 C# 和 Mono 编写游戏。我执行游戏循环并在窗口空闲时进行渲染（也就是说，当消息队列为空时）。我了解如何在 Windows 上执行此操作（使用 P/Invoke 从“User32.dll”导入 PeekMessage），但我不知道如何在 Linux 构建中获取有关消息队列状态的相同信息。我已经浏览了 Github 上的 Mono 存储库，它看起来不像直接访问消息队列被暴露。我正在运行的 Linux 版本是 Peppermint，如果有帮助的话。对此的任何指导将不胜感激。

我想写一个像DoEvents()C++ 一样的函数。

我发现DoEvents 等效于 C++？在 C/C++中，哪个函数类似于 DoEvents( )。

这是代码：

我有两个问题：

Q1。Linux 中的 DoEvent() 等价物是什么？

Q2。当我尝试使用 Qt creator 在 Windows 上使用它时出现错误。

错误 1：未知类型名称“味精”

错误 2：使用未声明的标识符“PM_NOREMOVE”

请问有什么帮助吗？

我正在调查应用程序挂起（winforms）。它只发生在客户机器上。他们从冻结过程中为我们提供了 dmp。但我不确定如何解释数据。

我将文件加载到 WinDbg 中。

1. !dlk => 没有死锁

2. !分析-挂起

   FAULTING_THREAD: 00003aec (这是主线程) WATSON_BKT_EVENT: AppHang ERROR_CODE: (NTSTATUS) 0xcfffffff - EXCEPTION_CODE_STR: cfffffff DERIVED_WAIT_CHAIN:

   Dl Eid Cid WaitType

   ---

   0 3ae8.3aec COM
   => 对我来说看起来像是主线程上的 COM 问题

3. !转储堆栈

   user32!_PeekMessage+0x42, 调用 win32u!NtUserPeekMessage combase!CCliModalLoop::MyPeekMessage+0x52, 调用 user32!PeekMessageW user32!PeekMessageW+0x149, 调用 user32!_PeekMessage user32!PeekMessageW+0x149, 调用 user32!_PeekMessage combase!CCliModalLoop::MyPeekMessage+ 0x52, 调用 user32!PeekMessageW combase!CCliModalLoop::MyPeekMessage+0x52, 调用 user32!PeekMessageW combase!CCliModalLoop::HandleWakeForMsg+0x13b, 调用 combase!CCliModalLoop::SetPointerInputModeAsAppropriateForQueueAttachmentConditions combase!CCliModalLoop::PeekRPCAndDDEMessage+comdalLoop::PeekRPCAndDDEMessage+0x49! MyPeekMessage combase！CCliModalLoop::RevertToNormalPointerInputMode+0x1d，调用 combase！CCliModalLoop::IsAttachedQueuePointerMessageReorderingAllowed combase！CCliModalLoop::BlockFn+0x262，调用 combase！CCliModalLoop::PeekRPCAndDDEMessage combase！ClassicSTAThreadWaitForHandles+0x9f, calling combase!CCliModalLoop::BlockFn clr!PrepareCriticalFinalizerObject+0x5e, calling clr!_security_check_cookie combase!CoWaitForMultipleHandles+0x76, calling combase!_guard_dispatch_icall_nop clr!MsgWaitHelper+0x8e, calling combase!CoWaitForMultipleHandles clr!ThreadStateNCStackHolder::~ThreadStateNCStackHolder+0x1c , 调用 clr!GetThread clr!Thread::DoAppropriateWaitWorker+0x2e6, 调用 clr!MsgWaitHelper clr!Thread::DoAppropriateWait+0x7d, 调用 clr!Thread::DoAppropriateWaitWorker clr!WaitHandleNative::CorWaitOneNative+0x161, 调用 clr!Thread::DoAppropriateWa KERNELBASE!CreateEventW+0x8c，调用 ntdll!RtlSetLastWin32Error ：CoWaitForMultipleHandles+0x76, 调用 combase!_guard_dispatch_icall_nop clr!MsgWaitHelper+0x8e, 调用 combase!CoWaitForMultipleHandles clr!ThreadStateNCStackHolder::~ThreadStateNCStackHolder+0x1c, 调用 clr!GetThread clr!Thread::DoAppropriateWaitrWorker!::::WaitHel DoAppropriateWait+0x7d, 调用 clr!Thread::DoAppropriateWaitWorker clr!WaitHandleNative::CorWaitOneNative+0x161, 调用 clr!Thread::DoAppropriateWait KERNELBASE!CreateEventW+0x8c, 调用 ntdll!RtlSetLastWin32Error :CoWaitForMultipleHandles+0x76, 调用 combase!_guard_dispatch_icall_nop clr!MsgWaitHelper+0x8e, 调用 combase!CoWaitForMultipleHandles clr!ThreadStateNCStackHolder::~ThreadStateNCStackHolder+0x1c, 调用 clr!GetThread clr!Thread::DoAppropriateWaitrWorker!::::WaitHel DoAppropriateWait+0x7d, 调用 clr!Thread::DoAppropriateWaitWorker clr!WaitHandleNative::CorWaitOneNative+0x161, 调用 clr!Thread::DoAppropriateWait KERNELBASE!CreateEventW+0x8c, 调用 ntdll!RtlSetLastWin32Error :DoAppropriateWaitWorker clr!WaitHandleNative::CorWaitOneNative+0x161, 调用 clr!Thread::DoAppropriateWait KERNELBASE!CreateEventW+0x8c, 调用 ntdll!RtlSetLastWin32Error :DoAppropriateWaitWorker clr!WaitHandleNative::CorWaitOneNative+0x161, 调用 clr!Thread::DoAppropriateWait KERNELBASE!CreateEventW+0x8c, 调用 ntdll!RtlSetLastWin32Error :

我不确定如何进一步调查/解释这一点。从堆栈中，我猜想发生一些 COM 事情的线程没有响应。对“PeekMessage”的调用可能表明消息队列损坏/无响应。带有“SetPointerInputModeAs...”的行对我来说似乎也很可疑。

任何建议或想法任何人？

亲切的问候

如何查看 Azure 服务总线主题中的计划消息？

根据这篇文章：

https://github.com/MicrosoftDocs/azure-docs/issues/59641

所以我不能在“ServiceBusReceiver”上使用“PeekMessagesAsync”

使用“ServiceBusAdministrationClient”，我可以获得主题中计划消息的数量，但我真的很想自己掌握消息......

任何帮助将不胜感激....

在GUI自动化服务的开发中，我们的团队面临着无法正确处理WM_LBUTTONUP消息的问题。

目标是拦截 WM_LBUTTONUP，禁用活动窗口，完成我们的工作并显示带有 YES 和 NO 按钮的 MessageBox：

1. 如果点击是，我们手动做我们的事情；
2. 否则，如果单击 NO，则不执行任何操作，但在这两种情况下，我们都必须阻止单击的窗口接收此消息，然后启用冻结窗口。

尝试使用 WH_MOUSE_LL 钩子，但点击的窗口在我们可以做任何事情之前收到点击。尝试使用 WH_GETMESSAGE 钩子，我们做所有事情，但在启用接收 WM_LBUTTONUP 后，用户独立回答禁用的窗口。

消息循环的代码（在 Service.exe 中）：

与 WH_MOUSE_LL 一起使用的代码（在 Service.dll 中）：

以及与 WH_GETMESSAGE 一起使用的代码（在 Service.dll 中）：

所以我的问题是如何拦截 WM_LBUTTONUP 消息并阻止目标窗口接收到该消息？

我正在使用 ServiceBusReceiver（我想继续使用）从服务总线上的死信队列中读取。

但是，receiver.PeekMessagesAsync(550) 最多只能从死信队列中获取 250 条消息？？？我怎样才能改变这个？我已经将它设置为获取 550 条消息，所以不知道该怎么做。

dlqCount 由于某种原因不会超过 250？int maxMessages 参数似乎在这个数字之上不起作用？