Здравствуйте, Andrew S, Вы писали:
AS>>>>AS>>>>When the user presses and releases a key, presses and releases a mouse button, or moves the mouse, the device driver for the hardware device appends a hardware event to the SHIQ, which wakes up the RIT. The RIT then extracts the entry from the SHIQ and translates the event into the appropriate WM_KEY*, WM_?BUTTON*, or WM_MOUSEMOVE message. The translated message is then appended to the appropriate thread's virtualized input queue (VIQ)
AS>>>>AS>>>>You can force two or more threads to share the same virtualized input queue and local input state variables by using the AttachThreadInput function
AF>>>На самом деле, нет. Все перечисленные выше сообщения посылаются конкретному окну, так что получит их тот поток, который владеет окном. Другое дело, что после AttachThreadInput события ввода в двух потоках будут сериализованы (именно в силу того, что они будут совместно использовать одну VIQ).
AS>Знаем, что не получает — тут уже писали. Т.е. в данном случае Рихтер ошибается? По-крайней мере, интерпретировать его по-другому достаточно сложно — он пишет, что эти сообщения помещаются в VIQ, а AttachThreadInput расшаривает эти VIQ. Или тут уже собственно Get\PeekMessage будет выбирать только сообщения "своего" потока?
Рихтер не ошибается. Virtualized input queue — это не то же самое, что message queue. И то, что потоки разделяют одну VIQ, не значит, что поток сможет получать сообщения, предназначенные другому потоку. Это означает, что поток не получит никаких своих событий ввода, пока другой поток не обработает свои.
