- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
long __stdcall wndproc(HWND wnd, unsigned int message, WPARAM wparam, LPARAM lparam)
{
switch(message)
{
case WM_USER + 100:
{
char data[128];
fill_data(data);
PostMessage(wnd, WM_USER + 666, 0, (LPARAM)data);
return 0;
}
case WM_USER + 666:
{
char * data = (char *)lparam;
use_data(data);
return 0;
}
//etc
Follow us!
Кстати, на 64-битной архитектуре возвращаемое значение поплывёт - скажем спасибо MS за 32-битный long. Нельзя было объявить как LRESULT или тогда уж LONG_PTR?
Видимо, комплексы свои они так компенсируют; косвенно на это указывает псевдоним LONG, выглядящий "толще" обычного long-а.
Хуйню сказал.
http://bit.ly/14RuoiA
А если соглашения нет, то порушить можно всё что угодно.
Я проверил, на WM_SIZE написал вывод в заголовок указателя на параметр Handle, при старте он не такой, как при работе, но во время работы он у меня не менялся.
Не такой он потому, что при первом вызове WM_SIZE (происходит при создании окна) на стеке отладчик видит только оконную функцию (видимо глубже там системные функции, которые он не различает), а при других WM_SIZE, инициированных пользователем, на стеке видно процедуру, в которой вызывается цикл обработки сообщений и 4 вызова оконной функции.
В общем, автор кода - очень везучий.
Если бы между приходами WM_USER+100 и WM_USER+666 закралось бы еще одно сообщение, то его обработчик вполне мог засрать область памяти, в которой лежала data, своими локальными переменными, и WM_USER+666 прочитал бы мусор.
Ну если память не изменяет - типичный цикл обработки сообщений выглядит так:Отсюда и гарантия одной глубины (но нет никакой гарантии, что тот же TranslateMessage или обработчики соседних сообщений не похерят данные в data).
Все правильно зделал!
Впрочем да, есть подвох в том, что можно вызвать ProcessMessages посреди сложного расчёта, но это не самый типичный случай.