Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Системное программирование и WinAPI > Как работает WM_SETTEXT ?

Автор: mekhanikus 10.5.2009, 15:49

Может кому-то вопрос покажется странным, но всетаки. Началось все с того, что я решил сделать subclassing стандартного STATIC'а, написать для него собственный WM_PAINT. Задача была, в общем то, успешно решена. Однако, в процессе тестирования программы выявилась неприятная особенность: в момент раздачи STATIC'ам (их много на форме) значений через WM_SETTEXT, происходит неприятное мерцание этих самых STATIC'ов. Насколько я понял, это происходит потому, что "The DefWindowProc function sets and displays the window text" причем делает это дефолтным шрифтом и цветом, а потом все это заново перерисовывается моим WM_PAINT'ом. Подскажите, как этого можно избежать? Можно ли отучить DefWindowProc перерисовывать текст? Или как самому обработать WM_SETTEXT?

Автор: andrew_121 10.5.2009, 18:04

Это из-за того что тело, вызывающее SendMessage() на ходится не в отдельном потоке.

Автор: GremlinProg 10.5.2009, 18:55

Цитата(mekhanikus @  10.5.2009,  17:49 ) Можно ли отучить DefWindowProc перерисовывать текст? можно просто блокировать на некоторое время перерисовку любого рода: блокировать: Код ::SendMessage(hwnd,WM_SETREDRAW,FALSE,0); разблокировать: Код ::SendMessage(hwnd,WM_SETREDRAW,TRUE,0); Цитата(mekhanikus @  10.5.2009,  17:49 ) Или как самому обработать WM_SETTEXT? субклассить Static и перехватывать WM_SETTEXT ( и WM_GETTEXT, если все еще нужно встроенное рисование static'а ) в процедуре окна, какие тут могут быть проблемы? ты ведь первое уже делаешь: Цитата(mekhanikus @  10.5.2009,  17:49 ) Началось все с того, что я решил сделать subclassing стандартного STATIC'а, проблема моргания контролов уже неоднократно обсуждалась, достаточно поискать по форуму WM_PAINT

Автор: J0ker 10.5.2009, 19:53

вам нужно заблокировать WM_ERASEBKGND - это он мерцает

Автор: mekhanikus 11.5.2009, 07:03

Цитата(GremlinProg @ 10.5.2009,  18:55) можно просто блокировать на некоторое время перерисовку любого рода: Надо будет покурить в эту сторону. Цитата(GremlinProg @ 10.5.2009,  18:55) субклассить Static и перехватывать WM_SETTEXT ( и WM_GETTEXT, если все еще нужно встроенное рисование static'а ) в процедуре окна, какие тут могут быть проблемы? Представте себе - проблема (для меня   ). Не смог найти куда засунуть текст, полученый в WM_SETTEXT. Пожалуйста пните в нужном направлении. Добавлено через 12 минут и 46 секунд Цитата(J0ker @ 10.5.2009,  19:53) вам нужно заблокировать WM_ERASEBKGND - это он мерцает Пробовал, не помогает. Причина, имхо, именно в реакции DefWindowProc на WM_SETTEXT.

Автор: J0ker 11.5.2009, 09:06

Цитата(mekhanikus @  11.5.2009,  07:03 ) Пробовал, не помогает. Причина, имхо, именно в реакции DefWindowProc на WM_SETTEXT такого попросту быть не может если вы перекрываете отрисовку и блокируете WM_ERACEBKGND то больше никто ничего не рисует если мерцание происходит в момент, когда ваш код перерисовывает контрол, то значит надо рисовать в буфер а потом копировать посредством BitBlt

Автор: Earnest 11.5.2009, 09:18

J0ker, не стоит быть столь категоричным, когда речь идет о старых контролах виндоус. Насчет статика утверждать не берусь, но вот комбобокс точно рисуется не только на WM_PAINT... Из вышесказанного, конечно, не следует, что аффтар все правильно сделал. Но такое вполне может быть (что отрисовка на  settext идет не через стандартный WM_PAINT). С другой стороны, если сделать контрол полностью OwnerDraw, то должно помочь - тогда действительно все под контролем.

Автор: J0ker 11.5.2009, 09:22

Цитата(mekhanikus @  10.5.2009,  15:49 ) Насколько я понял, это происходит потому, что "The DefWindowProc function sets and displays the window text" причем делает это дефолтным шрифтом и цветом, а потом все это заново перерисовывается моим WM_PAINT'ом вы неправильно понимаете процесс если что либо меняется для контрола, что требует его перерисовки, то контролу посылается WM_PAINT - если вы его (правильно) перехватили, то больше никто ничего в клиентской области рисовать не будет (за исключением, как я говорил выше, WM_ERACEBKGND)

Автор: Earnest 11.5.2009, 09:32

Цитата(J0ker @  11.5.2009,  10:22 ) если что либо меняется для контрола, что требует его перерисовки, то контролу посылается WM_PAINT  Как уже сказано, это не обязательно так, для некоторых старых контролов. Во всяком случае, комбобоксу не получается кастомизировать отрисовку без полного OwnerDraw, только перехватом WM_PAINT, а они со статиком ровестники, еще из Win 3 приползли, так что  там костыль на костыле, и вполне возможна "оптимизация" отрисовки.

Автор: J0ker 11.5.2009, 09:41

Цитата(Earnest @  11.5.2009,  09:18 ) J0ker, не стоит быть столь категоричным, когда речь идет о старых контролах виндоус стоит все контролы - это обычные окна Цитата(Earnest @  11.5.2009,  09:18 ) но вот комбобокс точно рисуется не только на WM_PAINT что значит "рисуется на"??? WM_PAINT - мессадж, дающий команду на перерисовку клиентской области - других нет - все, что рисуется в клиентской области рисуется в ответ на WM_PAINT я так подозреваю, что вы имеете ввиду owner-drawn контролы - но это уже из другой оперы Цитата(Earnest @  11.5.2009,  09:18 ) Но такое вполне может быть (что отрисовка на  settext идет не через стандартный WM_PAINT) не может Цитата(Earnest @  11.5.2009,  09:18 ) С другой стороны, если сделать контрол полностью OwnerDraw, то должно помочь - тогда действительно все под контролем.  под контролем родительского окна Цитата The WM_DRAWITEM message is sent to the parent window of an owner-drawn button, combo box, list box, or menu when a visual aspect of the button, combo box, list box, or menu has changed. это что называется "через <--->" ЗЫЖ я столь категоричен не от упрямства, а от опыта   Добавлено @ 09:43 Цитата(Earnest @  11.5.2009,  09:32 ) Как уже сказано, это не обязательно так, для некоторых старых контролов. Во всяком случае, комбобоксу не получается кастомизировать отрисовку без полного OwnerDraw, только перехватом WM_PAINT как уже сказано - получается не поручусь за выпадающий список, но все остальное перерисовывается на ура: http://www.codeproject.com/KB/combobox/ComboBox_appears_flat.aspx?display=Print

Автор: J0ker 11.5.2009, 09:58

да, заыл сказать, что листбокс - разговор отдельный

Автор: mekhanikus 11.5.2009, 11:08

Цитата(J0ker @ 11.5.2009,  09:06) такого попросту быть не может если вы перекрываете отрисовку и блокируете WM_ERACEBKGND то больше никто ничего не рисует Оказывается может. Сначала, чтоб проверить, получился ли у меня сабклассинг, я сделал пустой WM_PAINT, который возвращает 0. (знаю, что это не правильно, но, вопрос не в этом). После запуска программы сабкассированные статики остались пустыми (что и требовалось доказать). Однако, после раздачи значений через WM_SETTTEXT они появились. Добавлено через 8 минут и 32 секунды А кто, всетаки, скажет, где хранится этот самый текст окна (WindowText)? Если б я это узнал, то сам бы обработал WM_SETTEXT, без лишней отрисовки.

Автор: GremlinProg 11.5.2009, 11:17

Цитата(J0ker @  11.5.2009,  11:41 ) я так подозреваю, что вы имеете ввиду owner-drawn контролы - но это уже из другой оперы а что подозревать, когда Earnest, так и пишет: Цитата(Earnest @  11.5.2009,  11:18 ) если сделать контрол полностью OwnerDraw, то должно помочь Цитата(J0ker @  11.5.2009,  11:41 ) не поручусь за выпадающий список а выпадающий список не контрол? и почему не поручишься, только что ведь утверждал, что все рисуются только в ответ на WM_PAINT ) Цитата(J0ker @  11.5.2009,  11:22 ) если что либо меняется для контрола, что требует его перерисовки, то контролу посылается WM_PAINT - если вы его (правильно) перехватили, то больше никто ничего в клиентской области рисовать не будет это ты зря, бывают моменты, когда отрисовка идет, к примеру при захвате мыши (EDIT, RICHEDIT), т.е. она конечно на WM_PAINT тоже идет, но вот именно при "таскании" курсора по тексту, текущее выделение рисуется "на лету", перерисовка окна тут не происходит, накладно Добавлено через 7 минут и 38 секунд Цитата(mekhanikus @  11.5.2009,  13:08 ) А кто, всетаки, скажет, где хранится этот самый текст окна (WindowText)? это черный ящик, и дорога к нему закрыта Цитата(mekhanikus @  11.5.2009,  13:08 ) сам бы обработал WM_SETTEXT, без лишней отрисовки. обрабатывай сам, просто текст храни в своем буфере, чтобы при отрисовке обращаться только к нему

Автор: J0ker 11.5.2009, 17:23

Цитата(GremlinProg @  11.5.2009,  11:17 ) а выпадающий список не контрол? специфическая его часть Цитата(GremlinProg @  11.5.2009,  11:17 ) и почему не поручишься, только что ведь утверждал, что все рисуются только в ответ на WM_PAINT ) потому, что не рабботал с этой частью но не вижу причин, почему она должна быть исключением - так шо 99% - на WM_PAINT или WM_NCPAINT Цитата(GremlinProg @  11.5.2009,  11:17 ) это ты зря, бывают моменты, когда отрисовка идет, к примеру при захвате мыши (EDIT, RICHEDIT), т.е. она конечно на WM_PAINT тоже идет, но вот именно при "таскании" курсора по тексту, текущее выделение рисуется "на лету", перерисовка окна тут не происходит, накладно не вижу противоречия с моим высказыванием

Автор: GremlinProg 11.5.2009, 19:08

Цитата(J0ker @  11.5.2009,  19:23 ) специфическая его часть ну надо же, а я думал это обычный контрол, как и все а это оказывается какой-то хитрый специфический трюк винды не расстраивай меня J0ker, может ты еще будешь настаивать что и меню это не контрол, а какой-то очередной специфический трюк? я совсем тогда разочаруюсь ) Цитата(J0ker @  11.5.2009,  19:23 ) потому, что не рабботал с этой частью тогда и не нужно так категорично настаивать рисовать может кто угодно, где угодно и когда угодно другой вопрос - какие могут быть причины, чтобы не рисовать чего-либо на WM_PAINT Цитата(J0ker @  11.5.2009,  19:23 ) не вижу противоречия с моим высказыванием ну это уже совсем ни в какие ворота: Цитата(J0ker @  11.5.2009,  11:22 ) вы неправильно понимаете процесс если что либо меняется для контрола, что требует его перерисовки, то контролу посылается WM_PAINT - если вы его (правильно) перехватили, то больше никто ничего в клиентской области рисовать не будет (за исключением, как я говорил выше, WM_ERACEBKGND) от свои слов же не будешь отказываться я просто привел буквально самый очевидный пример, когда WM_PAINT добровольно вообще не посылается в контрол, пока не будет отпущена мышь как же нет противоречий-то? ps: конечно WM_PAINT ни кто ни кому не посылает (он генерируется в момент простоя, когда область перерисовки не пуста), это просто допустимый оборот речи в этом топике для краткости

Автор: J0ker 11.5.2009, 23:06

Цитата(GremlinProg @  11.5.2009,  19:08 ) ну надо же, а я думал это обычный контрол, как и все не все что вы видите на экране явлется окном - возможна отрисовка непосредственно на DC экрана Цитата(GremlinProg @  11.5.2009,  19:08 ) а это оказывается какой-то хитрый специфический трюк винды правда? что-то с трудом верится как я казал выше - с вероятностью 99% это окно хотя вам, конечно, виднее    Цитата(GremlinProg @  11.5.2009,  19:08 ) может ты еще будешь настаивать что и меню это не контрол, а какой-то очередной специфический трюк? с какого это перепою? Цитата(GremlinProg @  11.5.2009,  19:08 ) тогда и не нужно так категорично настаивать рисовать может кто угодно, где угодно и когда угодно тем не менее я настаиваю - рисует контрол сам на себе - исключительно собственно я не понимаю к чему вы пытаетесь подкопаться    Цитата(GremlinProg @  11.5.2009,  19:08 ) другой вопрос - какие могут быть причины, чтобы не рисовать чего-либо на WM_PAINT вы неправильно ставите вопрос какие могут быть причины, что-бы РИСОВАТЬ что-либо НЕ на WM_PAINT? - вот как раз тут всплывает прцесс выделения текста понимаете, данный вопрос не комутативен   Цитата(GremlinProg @  11.5.2009,  19:08 ) от свои слов же не будешь отказываться зачем??? даже повторю - больше никто ничего в клиентской области рисовать не будет - только и исключительно сам контрол Цитата(GremlinProg @  11.5.2009,  19:08 ) я просто привел буквально самый очевидный пример, когда WM_PAINT добровольно вообще не посылается в контрол, пока не будет отпущена мышь посылаются другие сообщения, причем самому себе WM_PAINT посылается когда необходимость перерисовки определяется извне, либо самим контролом дабы не дублировать функциональность совершенно очевидно, что при изменении внутреннего состояния контрола никто кроме него самого не может определить необходимость перерисовки Добавлено через 14 минут и 37 секунд Цитата(mekhanikus @  11.5.2009,  11:08 ) Оказывается может. Сначала, чтоб проверить, получился ли у меня сабклассинг, я сделал пустой WM_PAINT, который возвращает 0. (знаю, что это не правильно, но, вопрос не в этом). После запуска программы сабкассированные статики остались пустыми (что и требовалось доказать). Однако, после раздачи значений через WM_SETTTEXT они появились. Добавлено через 8 минут и 32 секунды А кто, всетаки, скажет, где хранится этот самый текст окна (WindowText)? Если б я это узнал, то сам бы обработал WM_SETTEXT, без лишней отрисовки.  у вас нет доступа к этому буферу сохраняете текст в свой буфер и вызываете InvalidateRect в WM_PAINT рисуете текст из своего буфера

Автор: GremlinProg 12.5.2009, 01:20

вообще-то я и не собирался прикапываться, просто предупредил твою очередную пустую упертость Цитата(J0ker @  12.5.2009,  01:06 ) правда? что-то с трудом верится как я казал выше - с вероятностью 99% это окно хотя вам, конечно, виднее   уже второй раз замечаю за тобой такой явный случай "перевертыша", причем как моих слов, так и своих, не надо использовать этот грязный способ убеждения, просто потому, что неправду видно в контексте и цитатах, а отношение к себе ты уже заведомо испортил, даже если был бы хоть на толику прав Цитата(J0ker @  12.5.2009,  01:06 ) как я казал выше - с вероятностью 99% это окно Цитата(J0ker @  11.5.2009,  19:23 ) так шо 99% - на WM_PAINT или WM_NCPAINT выше сказана очевидно совершенно другая мысль Цитата(J0ker @  12.5.2009,  01:06 ) тем не менее я настаиваю - рисует контрол сам на себе - исключительно а кто бы с тобой спорил, если бы ты именно на этом настаивал ) а в остальном, можно было не присваивать уже чужую точку зрения, ты же изначально ее и оспаривал странный у тебя однако способ выражать солидарность, всех облил грязью, нехорошо

Автор: mekhanikus 12.5.2009, 06:32

Цитата(GremlinProg @ 11.5.2009,  11:17) это черный ящик, и дорога к нему закрыта обрабатывай сам, просто текст храни в своем буфере, чтобы при отрисовке обращаться только к нему Понятно! Всем спасибо! Можно считать вопрос исчерпаным. p.s.Намечается два выхода: забить на мерцание, или создать свой класс окна (может оно и к лучшему? добавится функциональность).

Автор: GremlinProg 12.5.2009, 10:24

можно использовать свойства окна для хранения своего буфера: Код ... case WM_CREATE:   LPTSTR lpszBuffer = new _TCHAR[100];   ::SetProp(hwnd,_T("buffer"),(HANDLE)lpszBuffer);   break; case WM_DESTROY:   LPTSTR lpszBuffer = (LPTSTR)::GetProp(hwnd,_T("buffer"));   ::RemoveProp(hwnd,_T("buffer"));   delete[]lpszBuffer;   break; case WM_SETTEXT:   LPTSTR lpszBuffer = (LPTSTR)::GetProp(hwnd,_T("buffer"));   _tcsncpy(lpszBuffer,lpszSrc,100);   ::InvalidateRect(hwnd,NULL,TRUE);   return TRUE; case WM_PAINT:   LPTSTR lpszBuffer = (LPTSTR)::GetProp(hwnd,_T("buffer"));   ...   ::DrawText(...,lpszBuffer,...);   ...   break; ... return ::CallWindowProc(...); Цитата(mekhanikus @  12.5.2009,  08:32 ) создать свой класс окна если от класса STATIC ничего не нужно, то лучше конечно создать свой класс

Автор: mekhanikus 12.5.2009, 14:04

Во как интересно! Хороший примерчик! Распечатал, прибил на стенку - будем изучать.   Респект GremlinProg!

Автор: mekhanikus 12.5.2009, 14:20

А вот пример борьбы с мерцанием от MSDN: http://msdn.microsoft.com/en-us/library/ms969905.aspx Спасибо за ссылку J0ker'у

Автор: GremlinProg 12.5.2009, 15:28

там я еще строчку пропустил: Код case WM_SETTEXT: ... LPTSTR lpszSrc = (LPTSTR)lParam; ...

Автор: mekhanikus 13.5.2009, 14:52

Идея мне понравилась, только как поймать WM_CREATE для STATIC'а в диалоге? Что-то подсказывает мне, что это невозможно. Или я не прав?

Автор: GremlinProg 13.5.2009, 15:23

у тебя же subclassing STATIC'а, как не можешь поймать-то? WM_SETTEXT в любом случае на диалоге ловить бессмысленно, тебе же нужно поймать установку текста в  STATIC'е, для этого и нужен subclassing а создание STATIC'a на диалоге можно перехватить с помощью WM_PARENTNOTIFY, но без subclassingа это так же бессмысленно хотя, если будешь делать свой контрол вместо subclassing'а static'a, то все будет намного проще, сам выбирай (я бы STATIC вообще не использовал)

Автор: mekhanikus 14.5.2009, 03:50

Цитата WM_SETTEXT в любом случае на диалоге ловить бессмысленно, тебе же нужно поймать установку текста в  STATIC'е, для этого и нужен subclassing а создание STATIC'a на диалоге можно перехватить с помощью WM_PARENTNOTIFY, но без subclassingа это так же бессмысленно Значит так:  - в диалоге ловим WM_PARENTNOTIFY; (или для этого надо сабкластить диалог?)  - в нем WM_CREATE для STATIC'а;  - если наш, то делаем сабклассинг;  - в нашей WNDPROC для STATIC'а ловим WM_CREATE; Am I right? Цитата хотя, если будешь делать свой контрол вместо subclassing'а static'a, то все будет намного проще, сам выбирай (я бы STATIC вообще не использовал) Оставим на десерт.

Автор: GremlinProg 14.5.2009, 11:31

Цитата(mekhanikus @  14.5.2009,  05:50 ) в диалоге ловим WM_PARENTNOTIFY; (или для этого надо сабкластить диалог?) не надо Цитата(mekhanikus @  14.5.2009,  05:50 ) если наш, то делаем сабклассинг а, ну если так, то WM_PARENTNOTIFY вполне заменяет WM_INITDIALOG Цитата(mekhanikus @  14.5.2009,  05:50 )  в нашей WNDPROC для STATIC'а ловим WM_CREATE нет, WM_CREATE уже не придет, контрол создан, инициализацию всех контролов нужно проводить на WM_INITDIALOG, а сабклассинг следит только за WM_SETTEXT (и желательно WM_GETTEXT), WM_DESTROY и WM_PAINT, если нужно

Автор: mekhanikus 14.5.2009, 14:07

ОК! Будем пробовать.

Автор: mekhanikus 15.5.2009, 03:08

ВАУ! Это действительно работает!    Еще немного напряч мозги, и мне будет нравиться результат.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)