Все мои познания по сабжу носят теоретико-академико-умозрительный характер, потому такие вопросы:

1. Читал Рихтера. Возник вопрос — помещается ли WM_PAINT в очередь асинхронных сообщений — вроде как исходя из особенностей обработки этого сообщения, не должно — иначе GetMessage просто выбирала бы его из очереди и оно обрабатывалось бы как и другие.У Рихтера же говорится о QS_PAINT проверяя который GetMessage (уже после обработки синхронных, асинхронных, QS_QUIT, еще какой-то очереди) заполнит члены структуры MSG. Но, если сообщения WM_PAINT нету в очереди, а есть только флаг QS_PAINT, то каким образом GetMessage определяет параметр hwnd ? Или соответствующий hwnd где-то хранится? А как быть
если у потока несколько окон?
2. Если один поток вызвал SendMessage, а второй в этот момент что-то делает, то поток-отправитель вынужден ждать, когда поток-получатель обработает это синхронное сообщение. По словам Рихтера, в этот момент поток отправитель еще и может что-то делать — как это может быть? Что такое происходит в SendMessage, что позволяет потоку-отправителю еще и какие-то сообщения обрабатывать????
3. SendMessageTimeоut — есть SMTO_ABORTIFHUNG — как тут обстоит дело с параметром, задающим время таймаута? Т.е., чтобы определить, что поток "повис" (хотя может он что-то долго обрабатывает просто) — нужно 5 сек не вызывать GetMessage. Так вот, время моего таймаута согласуется с этими 5 секундами или нет? Т.е. если у меня таймаут 6 сек, то одну секунду ждать уже не буду? Может ли быть такое, что SendMessageTimeout решила, что поток — получатель висит, а сообщение ему все равно отправилось?

Отвечу на второй вопрос.
А>2. Если один поток вызвал SendMessage, а второй в этот момент что-то делает, то поток-отправитель вынужден ждать, когда поток-получатель обработает это синхронное сообщение. По словам Рихтера, в этот момент поток отправитель еще и может что-то делать — как это может быть? Что такое происходит в SendMessage, что позволяет потоку-отправителю еще и какие-то сообщения обрабатывать????
Обрабатываются так называемые Nonqueued Messages, т.е. сообщения, реально не помещаемые в очередь сообщений, а напрмямую попадающие в оконную процедуру.

V>Обрабатываются так называемые Nonqueued Messages, т.е. сообщения, реально не помещаемые в очередь сообщений, а напрмямую попадающие в оконную процедуру.

Извиняюсь за дремучесть. Как это может быть? Вот, допустим, поток вызвал SendMessage и управление из нее еще не вернулось. Как он может выполнить WndProc ?

А>Извиняюсь за дремучесть. Как это может быть? Вот, допустим, поток вызвал SendMessage и управление из нее еще не вернулось. Как он может выполнить WndProc ?
Ну я тоже не Рихтер , но как я понимаю, операционная система просто передает управление (вызывает) WndProc, передавая все параметры самостоятельно. Так я это понимаю.

V>Ну я тоже не Рихтер , но как я понимаю, операционная система просто передает управление (вызывает) WndProc, передавая все параметры самостоятельно. Так я это понимаю.

Ну да, вообще-то я по другому это тоже не могу объяснить. Какие сообщения являются non-queued?

Хотя, с другой стороны, непонятно нифига, как это виндовс может в потоке прервать выполнение какой-нить функции, выполнить другую, а потом продолжить выполнение первой

А>Ну да, вообще-то я по другому это тоже не могу объяснить. Какие сообщения являются non-queued?
ms-help://MS.MSDNQTR.2003JUL.1033/winui/winui/windowsuserinterface/windowing/messagesandmessagequeues/aboutmessagesandmessagequeues.htm#nonqueued_messages

Здравствуйте, Аноним, Вы писали:

V>>Обрабатываются так называемые Nonqueued Messages, т.е. сообщения, реально не помещаемые в очередь сообщений, а напрмямую попадающие в оконную процедуру.

А>Извиняюсь за дремучесть. Как это может быть? Вот, допустим, поток вызвал SendMessage и управление из нее еще не вернулось. Как он может выполнить WndProc ?

Все зависит от того, какому потоку принадлежит окно-получатель.
Если оно принадлежит тому же потоку, из которого вызывается SendMessage() то происходит вызов WndProc() так, как если бы вызов SendMessage() был заменен на WndProc() (наверное не в точности так... ).
Если же окно принадлежит другому потоку, то вызывающий поток приостанавливается и только после возврата из WndProc() другого потока продолжает свою работу

Т.е. получается, что если поток послал окну другого потока сообщение, то пока тот другой поток его не обработает, поток-отправитель не может обработать никакого сообщения?

Здравствуйте, Аноним, Вы писали:

А>Т.е. получается, что если поток послал окну другого потока сообщение, то пока тот другой поток его не обработает, поток-отправитель не может обработать никакого сообщения?

Да, в случае синхронного сообщения (посланного через SendMessage() ), так и происходит. А SendMessageTimeout() позволяет предотвратить зависание вызывающего потока, если вызываемый очень занят и не может ответить...

M>Да, в случае синхронного сообщения (посланного через SendMessage() ), так и происходит

т.е с окном потока отправителя я не могу сделать вообще ничего?

Здравствуйте, Аноним, Вы писали:

M>>Да, в случае синхронного сообщения (посланного через SendMessage() ), так и происходит

А>т.е с окном потока отправителя я не могу сделать вообще ничего?

Да. Чтобы что-то произошло с окном (перерисовка, перемещение, и т.д.), должен выполниться код в WndProc() (в этом же потоке, из к-рого произошел вызов SendMessage()), обрабатывающий соответствующее сообщение (WM_PAINT, WM_MOVE, и т.д.). А выполниться этот код не модет, потому что выполнение потока приостановлено в месте вызова SendMessage(). И не важно, как на это окно хотят повлиять, вызовом SendMessage() или PostMessage()...

Значит это у меня просто ambiqyuty в переводе А что там внутри SendMessage такое, что позволяет потоку ждать?

Здравствуйте, Аноним, Вы писали:

А>Значит это у меня просто ambiqyuty в переводе А что там внутри SendMessage такое, что позволяет потоку ждать?

Прошу прощения, напоролс

Это MSDN пишет:
The sending thread is blocked until the receiving thread processes the message. However, the sending thread will process incoming nonqueued messages while waiting for its message to be processed.

Ща разберемся

M>Ща разберемся

Дада, помогите, а то что-то я запутался (это я был анонимом)

Здравствуйте, wapi_newbie, Вы писали:

M>>Ща разберемся

_>Дада, помогите, а то что-то я запутался (это я был анонимом)

Насколько я понял, напряженно перечитывая MSDN, поток, вызывающий SendMessage, в любом случае ожидает завершения обработки сообщения другим потоком и при этом не может ничего делать. Но, как пишет все тот же MSDN, если вызываемая функция обработки оконных сообщений собирается в ответ на сообщение выполнять долго работающий код, то она может вернуть результат вызываемому потоку через ReplyMessage и продолжить выполнение долгого кода.

Вот пример кода из MSDN
case WM_USER + 5:
if (InSendMessage())
ReplyMessage(TRUE);

DialogBox(hInst, "MyDialogBox", hwndMain, (DLGPROC) MyDlgProc);
break;

Про ReplyMessage и IsSendMessage есть и у Рихтера вроде как. Темнят гады

Здравствуйте, wapi_newbie, Вы писали:

_>Про ReplyMessage и IsSendMessage есть и у Рихтера вроде как. Темнят гады

Рихтер — он хороший, правду пишет только в сносках мелким шрифтом
А насчет механизма работы? Ковырять нужно, объекты синхронизации используются наверняка...

M>Рихтер — он хороший, правду пишет только в сносках мелким шрифтом
M>А насчет механизма работы? Ковырять нужно, объекты синхронизации используются наверняка...

Надыбал еще какую-то недетскую книжищу