Re[3]: WM_PAINT "чужого" окошка
От: Pavel Dvorkin Россия  
Дата: 11.09.06 11:25
Оценка: 4 (2)
Здравствуйте, Everon, Вы писали:

E>Здравствуйте, apple-antonovka, Вы писали:


AA>>Грабли по-видимому в том что код твой должен быть в аресном пространстве того процесса, которому принадлежит окно (explorer.exe) .


E>Он там и находится. В прицепленой к explorer.exe библиотеке. Грабли не в сабклассинге, они именно в обработчике WM_PAINT. Видно, что стандартный обработчик здесь не подходит, нужно учитывать ещё какие-то нюансы...


А ресурсы откуда грузишь ?
Ты должен их загружать из часов (но там их нет, конечно) или из некоей DLL, которую можешь тут же подгрузить, но не из ресурсов того приложения, которым сабклассишь.
With best regards
Pavel Dvorkin
WM_PAINT "чужого" окошка
От: Everon  
Дата: 08.09.06 23:20
Оценка:
Подскажите, пожалуйста, кто знает.
Обрабатываю WM_PAINT (из подменённой WndProc) у часов в трее, и ничего не выходит Код стандартный (BeginPaint, CreateCompatibleDC, SelectObject, BitBlt, etc...). И всего-то хотелось налепить на них битмап загруженный из ресурсов (LoadImage), а в место этого ни битмапа, ни стандартного фона Если перекрыть их каким-то окном, то остаётся след от него. Как будто WM_PAINT и вовсе не обрабатыватся, хотя тот же код, на "родном" окне моей программы всё рисует ка надо. Где грабли-то?
Re: WM_PAINT "чужого" окошка
От: apple-antonovka  
Дата: 09.09.06 10:29
Оценка:
Грабли по-видимому в том что код твой должен быть в аресном пространстве того процесса, которому принадлежит окно (explorer.exe) .
Re[2]: WM_PAINT "чужого" окошка
От: Everon  
Дата: 09.09.06 11:53
Оценка:
Здравствуйте, apple-antonovka, Вы писали:

AA>Грабли по-видимому в том что код твой должен быть в аресном пространстве того процесса, которому принадлежит окно (explorer.exe) .


Он там и находится. В прицепленой к explorer.exe библиотеке. Грабли не в сабклассинге, они именно в обработчике WM_PAINT. Видно, что стандартный обработчик здесь не подходит, нужно учитывать ещё какие-то нюансы...
Re[3]: WM_PAINT "чужого" окошка
От: kero Россия  
Дата: 09.09.06 13:53
Оценка:
AA>>Грабли по-видимому в том что код твой должен быть в аресном пространстве того процесса, которому принадлежит окно (explorer.exe) .

E>Он там и находится. В прицепленой к explorer.exe библиотеке. Грабли не в сабклассинге, они именно в обработчике WM_PAINT. Видно, что стандартный обработчик здесь не подходит, нужно учитывать ещё какие-то нюансы...


В предположении, что с сабклассингом OK: не пробовали — на WM_PAINT свою обработку ПОСЛЕ родной CallWindowProc(*WM_PAINT*) ?
По всему, пашиным хозяевам позарез нужна война в Европе
(уверены — к ним не залетит, в предыдущих двух не залетало жеж)
Автор: kero
Дата: 21.07.14
Re[4]: WM_PAINT "чужого" окошка
От: Everon  
Дата: 09.09.06 14:08
Оценка:
Здравствуйте, kero, Вы писали:

K>не пробовали — на WM_PAINT свою обработку ПОСЛЕ родной CallWindowProc(*WM_PAINT*) ?


Я вообще не собирался отдавать WM_PAINT родному обработчику, ни до, ни тем более после себя.
Re[5]: WM_PAINT "чужого" окошка
От: kero Россия  
Дата: 09.09.06 14:48
Оценка:
А как насчет обработки WM_PRINTCLIENT в TrayNotifyWnd ?
По всему, пашиным хозяевам позарез нужна война в Европе
(уверены — к ним не залетит, в предыдущих двух не залетало жеж)
Автор: kero
Дата: 21.07.14
Re[6]: WM_PAINT "чужого" окошка
От: Everon  
Дата: 09.09.06 15:01
Оценка:
Здравствуйте, kero, Вы писали:

K>А как насчет обработки WM_PRINTCLIENT в TrayNotifyWnd ?


Тоесть оставить часы в покое и мучать их родителя? Можно ли будет рисовать оттуда, или просто нужно ещё и трей сабклассить?

Я так понял, что сами часы даже бэкграунда своего не имеют, его рисует TrayNotifyWnd. Нашел способ заставить его это делать путём посылки этого самого WM_PRINTCLIENT (предворительно поиграв с SetWindowOrgEx) — фон появился, но битмапа по-прежнему нет. Хотя BitBlt вроде бы выполняется успешно
Re[3]: WM_PAINT "чужого" окошка
От: apple-antonovka  
Дата: 09.09.06 15:21
Оценка:
Рекомендую глянуть еще на WM_ERASEBKGND. Но чтото мне подсказывает что грабли таки в вашей рисовалке.
Re[4]: WM_PAINT "чужого" окошка
От: kero Россия  
Дата: 09.09.06 18:01
Оценка:
AA>Рекомендую глянуть еще на WM_ERASEBKGND.

А можно и так: LoadImage, CreatePaternBrush, SetClassLong(GCL_HBRBACKGROUND).
Тогда и WM_PAINT обрабатывать, пожалуй, не придется. Разве что WM_SIZE стоит предусмотреть.
По всему, пашиным хозяевам позарез нужна война в Европе
(уверены — к ним не залетит, в предыдущих двух не залетало жеж)
Автор: kero
Дата: 21.07.14
Re[4]: WM_PAINT "чужого" окошка
От: Everon  
Дата: 11.09.06 11:49
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А ресурсы откуда грузишь ?

PD>Ты должен их загружать из часов (но там их нет, конечно) или из некоей DLL, которую можешь тут же подгрузить, но не из ресурсов того приложения, которым сабклассишь.

Да, да... Мне должно быть стыдно, ресурсы грузил из своего EXE, да ещё и по WM_CREATE своего же окна , пока не понял, что hImage, полученный в моём процессе, в процессе эксплорера ничего не значит. В общем, переселил картинки в ресурсы DLL, и загружаю их по DLL_PROCESS_ATTACH, при загрузке в эксплорер — работает!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.