не все что вы видите на экране явлется окном - возможна отрисовка непосредственно на DC экрана


правда? что-то с трудом верится
как я казал выше - с вероятностью 99% это окно
хотя вам, конечно, виднее   


с какого это перепою?


тем не менее я настаиваю - рисует контрол сам на себе - исключительно
собственно я не понимаю к чему вы пытаетесь подкопаться   


вы неправильно ставите вопрос
какие могут быть причины, что-бы РИСОВАТЬ что-либо НЕ на WM_PAINT? - вот как раз тут всплывает прцесс выделения текста
понимаете, данный вопрос не комутативен  


зачем???
даже повторю - больше никто ничего в клиентской области рисовать не будет - только и исключительно сам контрол


посылаются другие сообщения, причем самому себе
WM_PAINT посылается когда необходимость перерисовки определяется извне, либо самим контролом дабы не дублировать функциональность
совершенно очевидно, что при изменении внутреннего состояния контрола никто кроме него самого не может определить необходимость перерисовки

Добавлено через 14 минут и 37 секунд

у вас нет доступа к этому буферу
сохраняете текст в свой буфер и вызываете InvalidateRect
в WM_PAINT рисуете текст из своего буфера

вообще-то я и не собирался прикапываться,
просто предупредил твою очередную пустую упертость

уже второй раз замечаю за тобой такой явный случай "перевертыша", причем как моих слов, так и своих,
не надо использовать этот грязный способ убеждения, просто потому, что неправду видно в контексте и цитатах, а отношение к себе ты уже заведомо испортил, даже если был бы хоть на толику прав


выше сказана очевидно совершенно другая мысль

а кто бы с тобой спорил, если бы ты именно на этом настаивал )

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

Понятно!
Всем спасибо!
Можно считать вопрос исчерпаным.

p.s.Намечается два выхода: забить на мерцание, или создать свой класс окна (может оно и к лучшему? добавится функциональность).

можно использовать свойства окна для хранения своего буфера:


если от класса STATIC ничего не нужно, то лучше конечно создать свой класс

Во как интересно!
Хороший примерчик!

Распечатал, прибил на стенку - будем изучать.  

Респект GremlinProg!

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

Спасибо за ссылку J0ker'у

там я еще строчку пропустил:

Идея мне понравилась, только как поймать WM_CREATE для STATIC'а в диалоге?

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

Это сообщение отредактировал(а) mekhanikus - 13.5.2009, 14:54

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

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

Значит так:
 - в диалоге ловим WM_PARENTNOTIFY; (или для этого надо сабкластить диалог?)
 - в нем WM_CREATE для STATIC'а;
 - если наш, то делаем сабклассинг;
 - в нашей WNDPROC для STATIC'а ловим WM_CREATE;
Am I right?

Оставим на десерт.   

не надо

а, ну если так, то WM_PARENTNOTIFY вполне заменяет WM_INITDIALOG

нет, WM_CREATE уже не придет, контрол создан,
инициализацию всех контролов нужно проводить на WM_INITDIALOG, а сабклассинг следит только за WM_SETTEXT (и желательно WM_GETTEXT), WM_DESTROY и WM_PAINT, если нужно

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

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