Handle of Window in wndProc

Есть несколько окон, создавались они одним классом, и привязанны к одному обработчику wndproc. Нужно выудить какое из окон присылает команду, например в WM_CREATE.

Изначально делал окна с стилем CHILD и указывал родителем - основное окно приложения, флаг HMENU заполнял статическим числом для каждого окна. Однако задача немного изменилась, и CHILD флаг пришлось убрать, в месте с ним и hwndparent теперь NULL, и вылезла ошибка 1401 (пришлось и HMENU убрать).

Раньше работало так:
Но теперь нету HMENU (т.е. идентификатора), а глобальные hWin[0] (которые я указывал при CreateWindow) не соответствуют hDlg.. т.е. вот так не работает, хотя поидее должно:
Почему и как исправить?

0

Т.е. в WinProc вам нужно определить что это за окно? Почему просто при создании окна не сохранять хендлы в массив?

Добавлено через 17 минут
Т.е. получается делаем массив структур. В структуре два поля, одно поле это хэндл окна (полученный от CreateWindow), другое id по которому окно определяется из WndProc. Как то так.

0

Сообщение от jupman при создании окна не сохранять хендлы в массив?

Они сохранены, gWin[0] это 0 элемент этого HWND массива.

Только что тестировал.. Перед вызовом WM_CREATE в функцию попадает ещё 7 сообщений, установка пера, и т.п.. И в момент когда приходит WM_CREATE - его хэндл оказывается равен NULL. (и лишь после обработки WM_CREATE глобальный хэндл принимает значение, т.е. завершается работа функции CreateWindow, кто бы знал что вот так вот это происходит)
В общем то пока что единственный выход который я пока что нашёл - кривой, получать GetWindowText, и через него уже выводить сам HWND)

В общем получилось то что лишь после обработки WM_CREATE, hDlg (переменная самой wndproc) уже примет правильное значение, ровно как и сам глобальный хэндл.
Косяк майкрософтов лишь в том, что в winuser.h они определили номера WM_#### не в том порядке, в котором идёт обработка, т.е. если бы номера предустановки кисти, фона и т.д. были бы меньше чем WM_CREATE, то можно было бы просто обычным номером решить вопрос, но.. мде.

Добавлено через 1 минуту

Сообщение от jupman другое id по которому окно определяется из WndProc

Было так, пока окно было WM_CHILD, как только флаг я убрал, сразу вылезла ошибка и HMENU параметр пришлось так же поставить в NULL.

0

Сообщение от Izual И в момент когда приходит WM_CREATE - его хэндл оказывается равен NULL.

А может тогда через последний параметр CreateWindow WM_CREATE информировать.

lpParam [in, optional] Type: LPVOID A pointer to a value to be passed to the window through the CREATESTRUCT structure (lpCreateParams member) pointed to by the lParam param of the WM_CREATE message. This message is sent to the created window by this function before it returns.

0

Используйте сообщение WM_NCCREATE

0

Operok, а толку то? Оно вообще раньше чем WM_CREATE приходит, и точно так же хэндл там НУЛЛ.

Сообщение от jupman через последний параметр CreateWindow WM_CREATE информировать

Как вариант, но.. Это пятая нога.. Точно с таким же макаром я могу создать глобальную переменную, и через неё делать тоже самое.

В общем косяк.. Нарушение порядка... Надо было им сделать чтоб в NCCREATE - уже назначался hande. Вот он матерриальный мир... создатели не предусмотрели, что перед действием должна быть мысль, которая уже зарождает объект. Ну это так, филосовский отступ)

0

Сообщение от Izual Оно вообще раньше чем WM_CREATE приходит, и точно так же хэндл там НУЛЛ.

Параметр оконной процедуры HWND - нулл? Может вы хотите использовать результат возвращаемый функцией CreateWindow в обработчике WM_CREATE(NCCREATE), так ничего не получится, функция вернёт вым хендл не раньше чем будет обработано сообщение WM_CREATE.

0

Сообщение от Operok результат возвращаемый функцией CreateWindow в обработчике WM_CREATE(NCCREATE), так ничего не получится

Хотел, по типу как я делал с аргументом HMENU ID:
Ну так то понятно, если бы я передавал gWin[0] через ссылку в виде аргумента, то это может и можно было бы реализовать (майкрософтами), но так как сделано по другому - то вполне логично теперь, что эта переменная безполезна пока ф. CreateWindow не отработает.

Сообщение от Operok функция вернёт вым хендл не раньше чем будет обработано сообщение WM_CREATE

Ну да, не знал что CreateWindow уже посылает сообщения..

Сообщение от Operok Параметр оконной процедуры HWND - нулл?

Наверно нет, это я не смотрел, смотрел другое.. Видимо ошибся мальца когда писал выше. Вот кстати интересно а что же там.. Ведь по факту хэндла у окна ещё нету..

Вот интересно, а они в новых версиях винды исправляли такие недостатки? Айди значит не назначиш, WM_AFTERCREATE нету.. Недавно вот нашёл баг, что в одном цикле обработки нельзя ShowWindow много раз к одному окну использовать... Видать там таких багов полно, хоть пиши новые функции для всего этого..

Добавлено через 6 минут
Вот кстати возник вопрос, а есть ли что то ещё глубже чем WinApi? Т.е. то на чём оно построено, чтоб напрямую туда капнуть..

0

Izual, до сообщения WM_CREATE еще нет handle окна!
Я бы посоветовал сделать по-другому:
1) В WM_CREATE ничего не делаем
2) Получить и сохранить handle окна в массиве после выхода из функции создания окна
3) После создания всех окон, но до показа и обработки очереди сделать всю работу для всех окон (handle всех окон у нас есть) в момент создания.
4) При обработке сообщений ищем окно в массиве handle

1

Сообщение от _liv_ 3) После создания всех окон, но до показа и обработки очереди сделать всю работу для всех окон (handle всех окон у нас есть) в момент создания.

Ну да, как вариант создать свой WM_AFTERCREATE с помощью напильника..

...

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

Может кто подскажет, в QT тоже так же криво всё? (ну QT под windows понятное дело, что тот же самый WinAPI, но именно под линукс может всё чуть логичнее сделано?)

0