Значит, пробовал тройку разных вариантов. Начиная от патча explorer.exe и заканчивая SetWindowHookEx (локальный хук с обработчиком в длл). Последний вариант прекрасно работает, но только лишь на windows 10. На windows server 2012 r2 не летит событие WM_LBUTTONDOWN при нажатии на кнопку пуск. Вернее , оно не летит в окошечко кнопки пуск (hStart): Код (C): HWND hTray = FindWindowExW(0, 0, L"Shell_TrayWnd", 0); HWND hStart = FindWindowExW(hTray, 0, L"Start", 0); На win 10 летит именно туда, можно выполнить что-то типа такого: Код (C): SetWindowsHookExW(WH_MOUSE, GetProcAddress(hDll, "udll_init"), hDll, GetWindowThreadProcessId(hStart, 0)); Что сделал: настроил winspy++ на перехват сообщений всех окон, отфильтровал сообщения по WM_LBUTTONDOWN. Это сообщение все же летит при нажатии на кнопку пуск (см 1 картинку). Но когда пытаюсь посмотреть че это за хэндл такой - winspy ничего не показывает (см картинку 2). Забавно, но если очистить лог сообщений и нажать на кнопку заново - этот хэндл изменится. И такая фигня только при нажатии на кнопку пуск. Может, оно все как-то динамически генерируется? Как тогда понять, куда именно летит WM_LBUTTONDOWN? В самом хэндлере SetWindowsHookExW я делаю return -1 (сообщение после этого не передается в оконную процедуру, стартовое меню не открывается). Мне как бы это и нужно: заблокировать открытие стартового меню и вместо него рисовать свое окно. Я знаю крайне кривой способ решения этой задачи: поверх кнопки пуск создать свою кнопу с z-индексом больше (оверлей). Но этот вариант заблокирует нажатие правой кнопки мыши, а этого бы не хотелось. Надеюсь на вашу помощь.
Инжектишься в explorer.exe, сабклассишь эту кнопку через SetWindowLongW(GWL_WNDPROC) и ловишь WM_LBUTTONDOWN в обработчике.
Есть вариант вместо локального хука ставить глобальный и проверять принадлежность x и y координат кнопке пуск, блокировать передачу. Вот только в таком случае, если поверх кнопку пуск будет какое-нибудь окно, на которое мы нажмем - клик заблокируется. См картинку
f13nd, сабклассинг тоже хотел попробовать, вот только хз какой хэндл у окна, которое обрабатывает WM_LBUTTONDOWN
Вроде бы окно с классом ImmersiveSwitchList (8.1 х64) Можно на всякий случай засабклассить все и проверять координаты
Можно сделать несколькими способами. Поставить хук WH_GETMESSAGE и ловить WM_LBUTTONDOWN; Поставить хук WH_MOUSE, WH_MOUSE_LL и проверять координаты (WindowFromPoint); Поставить event-хук (SetWinEventHook) EVENT_OBJECT_INVOKED или EVENT_OBJECT_STATECHANGE и проверять условия. Сабклассинг в explorer.exe. Проблемы могут возникнуть между 64/32 процессами, которые уже решаются в зависимости от выбранного способа.
Thetrik, про event хуки ничего не знал, прикольная штука, спасибо)) UbIvItS, вопрос решил, правда, решение так и не пригодилось.
unc1e, Суть в следующем. Вы можите надумать какие угодно задачи, для решения которых будет не достаточно гибкости гуй апи или же их использование перейдёт на низкоуровневый слой(это не апи, а уровень интерфейсов ядра). Правильный подход к задаче - вы должны реализовать простейший фильтр и отследить событие в um-km интерфейсе(конкретно APFN), тогда вы поймёте конкретный высокоуровневый механизм, который и необходим для решения. Это можно сделать и в отладчике. Тем более что по этим интерфейсам есть сурки.