Можно ли с помощью Win API подцепить визуальный стиль контролов какого либо приложения и использовать его для рисования своих контролов, например Winamp'а? Если это уж совсем экзотика, то подскажите пожалуйста как вообще создается такой интерфейс, ведь если смотреть Spy'ем то видно что окно Winamp'а состоит из обычных контролов WIN API, кнопок, слайдеров и тд.?
Здравствуйте, MentorX, Вы писали:
MX>Можно ли с помощью Win API подцепить визуальный стиль контролов какого либо приложения и использовать его для рисования своих контролов, например Winamp'а? Если это уж совсем экзотика, то подскажите пожалуйста как вообще создается такой интерфейс, ведь если смотреть Spy'ем то видно что окно Winamp'а состоит из обычных контролов WIN API, кнопок, слайдеров и тд.?
Например, сабклассингом. Подменяешь функцию обработки кнопок, слайдеров и тд — в них рисуешь свои контролы (в нужных сообщениях) — получаешь свой интерфейс. Spy-ем, кстати, видно "на глаз" — своя функция обработки или уже перехваченная.
Ещё вариант (имхо не очень удобный и хороший и вообще может не работать правильно) — хук сообщений окон. Но тут больше проблем с тем, что за окно и что с ним делать — много процессора сожрётся на разборах.
Через WinAPI подцепить — только если разработчики сделали рисовалку в wm_print. Тогда этим сообщением передаём окну hdc и на выходе получаем hdc с битмапом, в котором нарисован внешний вид контрола, сливаем и пользуемся
Здравствуйте, CEMb, Вы писали:
CEM>Здравствуйте, MentorX, Вы писали:
MX>>Можно ли с помощью Win API подцепить визуальный стиль контролов какого либо приложения и использовать его для рисования своих контролов, например Winamp'а? Если это уж совсем экзотика, то подскажите пожалуйста как вообще создается такой интерфейс, ведь если смотреть Spy'ем то видно что окно Winamp'а состоит из обычных контролов WIN API, кнопок, слайдеров и тд.?
CEM>Например, сабклассингом. Подменяешь функцию обработки кнопок, слайдеров и тд — в них рисуешь свои контролы (в нужных сообщениях) — получаешь свой интерфейс. Spy-ем, кстати, видно "на глаз" — своя функция обработки или уже перехваченная.
CEM>Ещё вариант (имхо не очень удобный и хороший и вообще может не работать правильно) — хук сообщений окон. Но тут больше проблем с тем, что за окно и что с ним делать — много процессора сожрётся на разборах.
CEM>Через WinAPI подцепить — только если разработчики сделали рисовалку в wm_print. Тогда этим сообщением передаём окну hdc и на выходе получаем hdc с битмапом, в котором нарисован внешний вид контрола, сливаем и пользуемся
Хм, интересно. А что за wm_print? И можно поконкретней по поводу сабклассинга, в каком месте нужно писать код отрисовки, на WM_PAINT или нужно обрабатывать XX_OWNERDRAW?
Здравствуйте, MentorX, Вы писали:
MX>Можно ли с помощью Win API подцепить визуальный стиль контролов какого либо приложения и использовать его для рисования своих контролов, например Winamp'а? Если это уж совсем экзотика, то подскажите пожалуйста как вообще создается такой интерфейс, ведь если смотреть Spy'ем то видно что окно Winamp'а состоит из обычных контролов WIN API, кнопок, слайдеров и тд.?
Цеплять "визуальный стиль контролов другого приложения" — это извращение в чистом виде, если разработчик того приложения не предоставил соответствующую библиотеку.
Для создания "такого" интерфейса используются разные подходы, поищите немного, уверен, что найдёте в том числе и про винамп.
Здравствуйте, MentorX, Вы писали:
MX>>>Можно ли с помощью Win API подцепить визуальный стиль контролов какого либо приложения и использовать его для рисования своих контролов, например Winamp'а? Если это уж совсем экзотика, то подскажите пожалуйста как вообще создается такой интерфейс, ведь если смотреть Spy'ем то видно что окно Winamp'а состоит из обычных контролов WIN API, кнопок, слайдеров и тд.?
CEM>>Например, сабклассингом. Подменяешь функцию обработки кнопок, слайдеров и тд — в них рисуешь свои контролы (в нужных сообщениях) — получаешь свой интерфейс. Spy-ем, кстати, видно "на глаз" — своя функция обработки или уже перехваченная.
CEM>>Ещё вариант (имхо не очень удобный и хороший и вообще может не работать правильно) — хук сообщений окон. Но тут больше проблем с тем, что за окно и что с ним делать — много процессора сожрётся на разборах.
CEM>>Через WinAPI подцепить — только если разработчики сделали рисовалку в wm_print. Тогда этим сообщением передаём окну hdc и на выходе получаем hdc с битмапом, в котором нарисован внешний вид контрола, сливаем и пользуемся
Я сейчас сам делаю приложение со своей графической обёрткой поверх виндовых отрисовок
MX>Хм, интересно. А что за wm_print?
сообщение это, ещё есть wm_printclient для клиентской области, если отдельно.
Оба используются для получения _полного_ изображения содержимого окна. Но обработчик окна должен поддерживать wm_print, иначе будет просто чёрный квадрат. Все стандартные контролы его поддерживают(если msdn не врёт).
MX>И можно поконкретней по поводу сабклассинга, в каком месте нужно писать код отрисовки, на WM_PAINT или нужно обрабатывать XX_OWNERDRAW?
Ну, тут сложно сказать. Но на WM_PAINT точно надо. На WM_NCPAINT — отрисовка неклиентской части окна, если она есть. Плюс некоторые окна, например кнопки отрисовываются, не через WM_PAINT, а напрямую, при нажатии на них мышкой, или клавиатурой. Так же все окна перерисовываются на WM_ENABLE. Короче, надо смотреть, что в приложении "твориться" с контролами в процессе работы, и соответствующие события обкладывать отрисовкой. В конце WM_PAINT надо делать ValidateRect, иначе WM_PAINT снова позовётся.
