Знающие люди, подскажите пож-та: я соединяю
очереди ввода 2-х потоков (одного процесса) с помощью AttachThreadInput:
AttachThreadInput(thread1Id, thread2Id, TRUE);
Могу ли я из читать сообщения, поступающие в thread1
в цикле ожидания сообщений thread2 ???
Другими словами, попадут ли нажатия клавиш в окно потока thread1
в очередь thread2? Или они будут обрабатываться только потоком
thread1?
18.08.04 13:57: Перенесено модератором из 'Delphi & Builder' — Hacker_Delphi
Здравствуйте, Begemote, Вы писали:
B>Знающие люди, подскажите пож-та: я соединяю B>очереди ввода 2-х потоков (одного процесса) с помощью AttachThreadInput:
B>
B>Могу ли я из читать сообщения, поступающие в thread1 B>в цикле ожидания сообщений thread2 ??? B>Другими словами, попадут ли нажатия клавиш в окно потока thread1 B>в очередь thread2? Или они будут обрабатываться только потоком B>thread1?
Третий параметр, если не ошибаюсь, за это и отвечает. Но вам лучше все таки заглянуть в MSDN
B>>Могу ли я из читать сообщения, поступающие в thread1 B>>в цикле ожидания сообщений thread2 ??? B>>Другими словами, попадут ли нажатия клавиш в окно потока thread1 B>>в очередь thread2? Или они будут обрабатываться только потоком B>>thread1?
Вобщем-то функция для этого как раз ипредназначена.
Здравствуйте, Guard_h4s, Вы писали:
G_>Здравствуйте, Begemote, Вы писали:
B>>Знающие люди, подскажите пож-та: я соединяю B>>очереди ввода 2-х потоков (одного процесса) с помощью AttachThreadInput:
B>>
B>>Могу ли я из читать сообщения, поступающие в thread1 B>>в цикле ожидания сообщений thread2 ??? B>>Другими словами, попадут ли нажатия клавиш в окно потока thread1 B>>в очередь thread2? Или они будут обрабатываться только потоком B>>thread1?
G_>Третий параметр, если не ошибаюсь, за это и отвечает. Но вам лучше все таки заглянуть в MSDN
заглядывал уже везде, и в MSDN в частности. Получается у меня так:
Очередь ввода потока1 присоединена к очереди потока2.
Поток1 получает сообщения когда его окно активно,
поток2 получает сообщения когда активно его окно.
Выходит, что поток2 не может читать сообщения для потока1.
У них только переменные состояния локального ввода общие и всё?
Здравствуйте, Begemote, Вы писали:
B>Здравствуйте, Guard_h4s, Вы писали:
G_>>Здравствуйте, Begemote, Вы писали:
B>>>Знающие люди, подскажите пож-та: я соединяю B>>>очереди ввода 2-х потоков (одного процесса) с помощью AttachThreadInput:
B>>>
B>>>Могу ли я из читать сообщения, поступающие в thread1 B>>>в цикле ожидания сообщений thread2 ??? B>>>Другими словами, попадут ли нажатия клавиш в окно потока thread1 B>>>в очередь thread2? Или они будут обрабатываться только потоком B>>>thread1?
G_>>Третий параметр, если не ошибаюсь, за это и отвечает. Но вам лучше все таки заглянуть в MSDN
B>заглядывал уже везде, и в MSDN в частности. Получается у меня так: B>Очередь ввода потока1 присоединена к очереди потока2. B>Поток1 получает сообщения когда его окно активно, B>поток2 получает сообщения когда активно его окно. B>Выходит, что поток2 не может читать сообщения для потока1. B>У них только переменные состояния локального ввода общие и всё?
Эх, у меня сейчас нету Рихтера под рукой, там все было классно описано.
Советую почитать у него.(глава 26 или 27 кажется)
Здравствуйте, Guard_h4s, Вы писали:
G_>Здравствуйте, Begemote, Вы писали:
B>>Здравствуйте, Guard_h4s, Вы писали:
G_>>>Здравствуйте, Begemote, Вы писали:
B>>>>Знающие люди, подскажите пож-та: я соединяю B>>>>очереди ввода 2-х потоков (одного процесса) с помощью AttachThreadInput:
B>>>>
B>>>>Могу ли я из читать сообщения, поступающие в thread1 B>>>>в цикле ожидания сообщений thread2 ??? B>>>>Другими словами, попадут ли нажатия клавиш в окно потока thread1 B>>>>в очередь thread2? Или они будут обрабатываться только потоком B>>>>thread1?
G_>>>Третий параметр, если не ошибаюсь, за это и отвечает. Но вам лучше все таки заглянуть в MSDN
B>>заглядывал уже везде, и в MSDN в частности. Получается у меня так: B>>Очередь ввода потока1 присоединена к очереди потока2. B>>Поток1 получает сообщения когда его окно активно, B>>поток2 получает сообщения когда активно его окно. B>>Выходит, что поток2 не может читать сообщения для потока1. B>>У них только переменные состояния локального ввода общие и всё?
G_>Эх, у меня сейчас нету Рихтера под рукой, там все было классно описано. G_>Советую почитать у него.(глава 26 или 27 кажется)
Рихтера прочел в 1-ю очередь,но даже у него не совсем понятно — можно
ли получать сообщения, предназначенные для другого потока?
G_>>>>Третий параметр, если не ошибаюсь, за это и отвечает. Но вам лучше все таки заглянуть в MSDN
B>>>заглядывал уже везде, и в MSDN в частности. Получается у меня так: B>>>Очередь ввода потока1 присоединена к очереди потока2. B>>>Поток1 получает сообщения когда его окно активно, B>>>поток2 получает сообщения когда активно его окно. B>>>Выходит, что поток2 не может читать сообщения для потока1. B>>>У них только переменные состояния локального ввода общие и всё?
G_>>Эх, у меня сейчас нету Рихтера под рукой, там все было классно описано. G_>>Советую почитать у него.(глава 26 или 27 кажется)
B>Рихтера прочел в 1-ю очередь,но даже у него не совсем понятно — можно B>ли получать сообщения, предназначенные для другого потока?
Судя по Рихтеру, должны получать:
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)
You can force two or more threads to share the same virtualized input queue and local input state variables by using the AttachThreadInput function
Здравствуйте, Andrew S, Вы писали:
B>>Рихтера прочел в 1-ю очередь,но даже у него не совсем понятно — можно B>>ли получать сообщения, предназначенные для другого потока?
AS>Судя по Рихтеру, должны получать:
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
На самом деле, нет. Все перечисленные выше сообщения посылаются конкретному окну, так что получит их тот поток, который владеет окном. Другое дело, что после AttachThreadInput события ввода в двух потоках будут сериализованы (именно в силу того, что они будут совместно использовать одну VIQ).
-- Alex Fedotov
Re[7]: Кто хорошо знает ф-цию AttachThreadInput
От:
Аноним
Дата:
19.08.04 09:15
Оценка:
Здравствуйте, Alex Fedotov, Вы писали:
AF>Здравствуйте, Andrew S, Вы писали:
B>>>Рихтера прочел в 1-ю очередь,но даже у него не совсем понятно — можно B>>>ли получать сообщения, предназначенные для другого потока?
AS>>Судя по Рихтеру, должны получать:
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).
Согласен, эксперимент подтвердил именно это: система направляет сообщения тому потоку, чье окно сейчас в фокусе, несмотря на то, из какой очереди ввода она (система) его берет. Так что соединение очередей влияет только
на фокус ввода и др. переменные из THREADINFO.
B>>>>Рихтера прочел в 1-ю очередь,но даже у него не совсем понятно — можно B>>>>ли получать сообщения, предназначенные для другого потока?
AS>>>Судя по Рихтеру, должны получать:
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).
Знаем, что не получает — тут уже писали. Т.е. в данном случае Рихтер ошибается? По-крайней мере, интерпретировать его по-другому достаточно сложно — он пишет, что эти сообщения помещаются в VIQ, а AttachThreadInput расшаривает эти VIQ. Или тут уже собственно Get\PeekMessage будет выбирать только сообщения "своего" потока?
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, не значит, что поток сможет получать сообщения, предназначенные другому потоку. Это означает, что поток не получит никаких своих событий ввода, пока другой поток не обработает свои.
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 будет выбирать только сообщения "своего" потока?
AF>Рихтер не ошибается. Virtualized input queue — это не то же самое, что message queue. И то, что потоки разделяют одну VIQ, не значит, что поток сможет получать сообщения, предназначенные другому потоку. Это означает, что поток не получит никаких своих событий ввода, пока другой поток не обработает свои.
И тем не менее, вот выдержка из Рихтера же, алгоритм выбора сообщений:
The Algorithm for Extracting Messages from a Thread's Queue
When a thread calls GetMessage or PeekMessage, the system must examine the state of the thread's queue status flags and determine which message should be processed. Figure 26-2 and the following steps illustrate how the system determines which message the thread should process next.
If the QS_SENDMESSAGE flag is turned on, the system sends the message to the proper window procedure. Both the GetMessage and PeekMessage functions handle this processing internally and do not return to the thread after the window procedure has processed the message; instead, these functions sit and wait for another message to process.
If messages are in the thread's posted-message queue, GetMessage and PeekMessage fill the MSG structure passed to these functions, and then the functions return. The thread's message loop usually calls DispatchMessage at this point to have the message processed by the appropriate window procedure.
If the QS_QUIT flag is turned on, GetMessage and PeekMessage return a WM_QUIT message (where the wParam parameter is the specified exit code) and reset the QS_QUIT flag.
If messages are in the thread's virtualized input queue, GetMessage and PeekMessage return the hardware input message.
If the QS_PAINT flag is turned on, GetMessage and PeekMessage return a WM_PAINT message for the proper window.
If the QS_TIMER flag is turned on, GetMessage and PeekMessage return a WM_TIMER message.
Как же еще можно интерпретировать 2 приведенные выше высказывания вкупе с этим? Безусловно, я согласен, что выбирать "чужие" сообщения поток не будет, но на мой взгляд, Рихтер в данном случае некорректен. По-крайней мере, можно было бы уточнить, что сообщения выбираютсят только для своего потока.
AS>Как же еще можно интерпретировать 2 приведенные выше высказывания вкупе с этим? Безусловно, я согласен, что выбирать "чужие" сообщения поток не будет, но на мой взгляд, Рихтер в данном случае некорректен. По-крайней мере, можно было бы уточнить, что сообщения выбираютсят только для своего потока.
Да, у Рихтера описано не совсем однозначно для нашей ситуации. Если бы он (многоуважаемый Рихтер) сразу уточнил, что поток чужие сообщения никак не выберет, хоть все его очереди объедини, то и вопроса бы моего не было.
Спасибо всем, кто помог разобраться с этой ситуёвиной.
Здравствуйте, Begemote, Вы писали:
B>Знающие люди, подскажите пож-та: я соединяю B>очереди ввода 2-х потоков (одного процесса) с помощью AttachThreadInput:
B>
B>Могу ли я из читать сообщения, поступающие в thread1 B>в цикле ожидания сообщений thread2 ??? B>Другими словами, попадут ли нажатия клавиш в окно потока thread1 B>в очередь thread2? Или они будут обрабатываться только потоком B>thread1?
вообще для этого специально придумали особый тип хука
смысл какой в нем былбы, если бы можно было просто приаттачится и читать?
