发送和接收 Windows 消息 [英] Sending and receiving Windows messages

问题描述

Windows 消息似乎是在 Windows 操作系统上通知应用程序的好方法.它实际上运行良好，但我想到的问题很少:

Windows messages seems a good way to notify an application on Windows OSes. It actually works well, but few question comes up to my mind:

如何为 SendMessage 例程的 lparam 指定结构化数据(就像许多消息代码一样)?我的意思是...当然参数是一个指针，但是进程如何访问它呢?也许它是由发送/接收消息的进程加载的 DLL 分配的?

How to specify structured data to the lparam of the SendMessage routines (like many message codes does)? I mean... of course the parameter is a pointer, but how the process access to it? Maybe is it allocated by a DLL loaded by the processes sending/receiving the message?

是否可以共享消息结构化参数(在发送方和接收方之间)?它们被编组在 send 操作和 peeking 操作之间?如果是这种情况，是否可以通过修改结构化参数从调用方返回数据?这对 SendMessage 很有用，因为它是同步执行的，而不是 PostMessage 例程.

Is it possible to share message structured parameters (between sender and receiver)? They are marshalled between the send operation and the peeking operation? If this is the case, it is possible to return data from the caller by modifying the structured parameter? This could be usefull with SendMessage, since it is executed synchronously, instead the PostMessage routine.

其他疑问...

与 PostMessage 和 SendNotifyMessage 有什么区别?

如果应用程序在处理消息泵时向自身调用 SendMessage，是否可能导致死锁?

Is it possible to cause a deadlock in the case an application calls SendMessage to itself while processing the message pump?

推荐答案

如果消息是标准窗口的消息之一 - 通常消息 ID 介于 0 和 WM_USER 之间，则系统窗口消息调度逻辑包含用于编组结构到消息被分派到的任何进程.

If the message is one of the standard window's messages - usually with a message id between 0 and WM_USER, then the systems window message dispatching logic contains code to marshal the struct to the any processes the message is dispatched to.

WM_USER 以上的消息没有得到这样的处理——这包括 Windows 95 引入的所有常见的控制消息——你不能结束任何 LVM_*(列表视图消息)或其他新的控制消息到不同进程中的控件，并且返回结果.

Messages above WM_USER get no such treatment - and this includes all the common control messages introduced with Windows 95 - you cannot end any of the LVM_* (list view messages) or other new control messages to a control in a different process and get a result back.

WM_COPYDATA 被专门引入作为用户代码在进程之间编组任意数据的通用机制 - 在 WM_COPYDATA(或重用其他 Windows 标准消息)之外，没有办法让窗口使用消息队列机制自动编组结构化数据进入另一个进程.

WM_COPYDATA was specifically introduced as a general purpose mechanism for user code to marshal arbitrary data between processes - outside of WM_COPYDATA (or reusing other windows standard messages) there is no way to get windows to automatically marshal structured data using the message queue mechanism into another process.

如果是您自己的代码进行消息的发送和接收，您可以使用 dll 来定义共享内存部分，而不是发送指针(dll 在每个进程中可能基于不同)发送偏移量到共享内存阻止.

If it is your own code doing the sending AND receiving of messages, you could use a dll to define a shared memory section, instead of sending pointers (the dll might be based differently in each process) sends offsets to the shared memory block.

如果您想与不编组数据的外部应用程序交换结构化数据(例如从列表或树视图中提取数据)，那么您需要执行 dll 注入，以便您可以发送和处理来自in-进程".

If you want to exchange structured data with external applications that do not marshal their data (for example to extract data from a list or tree view) then you need to perform dll injection so you can send and process the message from "in-process".

SendNofityMessage 与 PostMessage 不同，因为 PostMessage 总是将消息放入消息队列中，而 SendNotifyMessage 的作用类似于同一进程中的 Windows 的 SendMessage.然后，即使目标窗口在另一个进程中，消息也会直接分派到未放置在已发布消息队列中的窗口进程，以便通过 GetMessage 或 PeekMessage 进行检索.

SendNofityMessage is different to PostMessage because PostMessage always puts the message in the message queue, whereas SendNotifyMessage acts like SendMessage for windows in the same process. Then, even if the target window is in another process, the message is dispatched DIRECTLY to the window proc not placed in the posted message queue for retreivel via GetMessage or PeekMessage.

最后有可能导致死锁——但是在阻塞"sendmessage 等待另一个线程回复时，SendMessage 将分派从其他线程发送(未发布)的消息——以防止死锁.这减少了大多数潜在的死锁，但仍有可能通过调用其他阻塞 api 或进入模态消息处理循环来创建死锁.

Lastly it is possible to cause a deadlock - however while in a "blocking" sendmessage waiting for another thread to reply, SendMessage will dispatch messages sent (not posted) from other threads - to prevent deadlocks. This mitigates most potential deadlocks, but its still possible to create deadlocks by calling other blocking apis, or going into modal message processing loops.

这篇关于发送和接收 Windows 消息的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！