Куда возвращает команда RET из WndProc

Хочшб я дам вразумительный ответ. ВндПроц кидает тебя в сисетму!!!!!Обратно!!!

 

Four-F

Ну это другое дело. Причем, насколько я понимаю, PeekMessage отличается от Get.., тем, что она возвращается из ядра независимо от наличия сообщения в очереди. Т.е. if Peek else Wait это и есть Get.

Точнее сказать, эквивалентом Get является Peek + проверка на WM_QUIT если true или Wait если false.

 

Bitfry

"Пункт 1 я толкую так:

Отработала процедура окна, строка ret посылает в user32. Если есть еще сообщение, то после колдовства виндов управление вернется к проге в её цикл сообщений. А если сообщений нет, нафига тогда цикл крутить, проц занимать?"



А я понимаю не так. В пункте 1 из Рихтера, речь идет об особом виде сообщения QS_SENDMESSAGE - а message sent by another thread or application - сообщение, которое было передано из другого потока или приложения (см. GetQueueStatus).

А крутить цикл или нет определяет GetMessage. Т.е. после ret и "колдовства виндов" управление вернется на инструкцию, следующую за Dispatch, затем в очередном цикле попадет в GetMessage, которая не вернет управление, пока не выдаст очередное сообщение.

Это если речь идет о цикле обработки queued сообщений. Но есть еще и nonqueued сообщения, которые передаются системой в WndProc напрямую. Это куча системных сообщений (типа WM_ACTIVATE и т.д.), а также сообщения передаваемые через SendMessage. Куда в этом случае в ИТОГЕ вернется управление, думаю ясно. Почему в ИТОГЕ, думаю тоже (см. S_T_A_S от 30.08 - рекурсивные вызовы).



PS: если система и может приостановить поток (например после WndProc), то вернуть управление она должна в то место где приостановила, иначе это действительно колдовство.

 

Ребята с меня благодарности!

После 8 сентября две чтивы из дневника чайника вроде бы опубликуют на cracklab.ru там я и выражу в письменном виде моё спасибо. И там же я изложу, как все понял, если в чем буду не прав, пишите.



PS: Тема интересная буду соображать.