Эта проблема решается проще - всего лишь флаг WS_CLIPCHILDREN родительскому окну, и дети не включаются в перерисовку. Что касается BeginPaint-EndPaint, то эта парочка делает по-крайней мере одну полезную вещь, которую без нее нужно делать руками (как ты и делаешь) - валидэйтит регион, для которого пришел WM_PAINT. А вовсе не приводит к перерисовке дочерних окон. 
Кроме того, при использовании вне-экранного буфера WM_ERASEBKGND обычно совсем затыкают (или просто можно поставить нулевую кисть классу окна при регистрации), и просто красят фон прямо во время отрисовки (если надо). А посылать для этого WM_ERASEBKGND с "левым" dc как-то криво, согласись.
Кроме того, использовать сообщение WM_PRINT не по назначению тоже не очень хорошо. Тем более всего-то надо функцию свою написать.
Т.е. что я хочу сказать - с точки зрения изучения "как оно все устроено" - ты разобрался прекрасно и твой код весьма полезен (в учебных целях). Но писать так в реальном проекте - боже упаси.
 

Весьма поспешное заявление, даже неудобно говорить это Ко-модератор'у. Я пишу только о том, что уже давно проверено. Не мне учить вас как проверить моё утверждение.
Не нужно так громко заявлять, тем более наскоро пробежавшись по тексту. О перерисовке целых контролов я и не говорил, перечитайте, пожалуйста пост.

WM_PAINT с "левым" dc тоже как-то криво, только это не я придумал, есть стандарт, вам не мешало бы его почитать.

Вы, видимо считаете, что WM_PRINT предназначен только для вывода на принтер? MSDN вас простит ). 

...да, да, WS_CLIPCHILDREN отсекает дочерние компоненты при прорисовке, но! Отсекает для родителя, т.е. папа не будет на них рисовать, BeginPaint просто перерисует НЕКлиентскую часть дочек и отсечет регионы их окон из папы, клиента дочек, он конечно же не тронет. Вы можете проверить, когда вызывается WM_NCPAINT, и убедиться в этом. Причем регион, который в дальнейшем выбирается в контекст устройства папы передается в WPARAM'етре. Это как раз и обуславливает такую, мягко говоря, непоследовательную прорисовку неклиентской области окна. WS_CLIPCHILDREN проблему не решит! 

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

Насчет неклиентской области дочерних окон и WS_CLIPCHILDREN ты, наверно, прав, но мне редко встречались контролы, где это имело бы значение... Что касается BeginPaint - повторюсь - эта функция ничего не перерисовывает! Да, она посылает ERASEBKGND, а также устанавливает регион отсечения, о чем и написано в MSDN... 

Кроме того, она избавляет тебя от возни с кареткой и пр., что иначе нужно делать вручную.
Подкорректировать регион отсечения (исключить из него неклиентскую часть дочерних окон, если приспичило) можно в любой момент - например, на ERASEBKGND (если оно в принципе приходит), а можно и прямо в WM_PAINT. Как-то я это делала на NCPAINT...

Что касается WM_PRINT, то стандартно оно из WM_PAINT не вызывается, и согласно MSDN используется для вывода "most commonly in a printer device". Хотя и необязательно, тут ты прав. Я хотела сказать лишь то, что неразумно посылать самому себе сообщения, упаковывать флаги и параметры, если это сообщение ты же сам и обрабатываешь. Проще функцию написать\вызвать. Уж не говоря о том что это несколько быстрее.
 

Есть один момент, вернее два, но один проще описать: давненько, когда я еще заморачивался с разными прибамбасами GDI, мне на глаза попалась такая вот задачка: допустим есть Edit, или Rich Edit - стандартно настроенные и нужно например за текстом показать ролик, или сделать анимированную подсветку части текста, причем, естественно, прибегать к формированию собственного текстового компонента было некогда. А сделать надо было корректно, без заплаток типа TRANSPARENT. Так вот решение оказалось довольно простым. Код который я выложил позволяет наследовать прорисовку анцестора, не родителя как до операции, так и после неё, причем дважды копировать девайс не нужно, ну и без морганий, соответственно. Просто сообщение WM_PRINT знают все системные компоненты, вернее его почти ни кто не обрабатывает, поэтому система ведет себя одинаково для всех контролов. Хм, это кстати единственный способ, который я тогда нашел.

Хотите - верьте, хотите - проверьте, повторять не буду. Дареному коню в зубы не глядят. Наступайте на грабли, на которые наступало уже несколько поколений программистов, я показал вам где эти грабли лежат, а остальное - дело техники.

Мозоль - не мозоль, но субординацию надо соблюдать!

Доверяй но проверяй, и не кричите, ради бога, пока не проверите! 

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

Не буду с тобой спорить, все как-то беспредметно. 
Я ведь не говорила, что твой код неправильный. Он просто избыточен и излишне усложнен, и пытается решить все возможные проблемы сразу.
В каждом конкретном контексте возможно свое, гораздо более простое решение.

Насчет ERASEBCKGND - на мой взгляд проще вызвать PatBlt или даже FillRect, поскольку вся прорисовка идет во вне-экранный буфер. Это мое мнение подтверждается многочисленными реализациями нестандартных контролов хотя бы на том же codeproject.
 
В конце концов у каждого свой опыт. 


Интересно, что ты хотел этим сказать? Кто тут из нас двоих начальник?   

На сколько я понял, у вас слишком большие амбиции, впрочем, флейм здесь неуместен. Если хотите пообщаться флудите в соответствующем этому месте. Я сильно сомневаюсь, что ваша репутация от этого возрастет, а мне до плюсиков нет дела, я - практик. Мое первое сообщение вы подвергли беспочвенной критике, тем самым вы сами себя спровоцировали на безграмотность. Так же сомневаюсь, что среди молодых к вам после этой темы будет доверие. И что теперь толку от ярлыка, который вы сами себе навесили. Начальник не тот кто главнее, а тот, кому можно доверить управление над подчиненными. Мои люди мне доверяют! А по поводу кода, я думаю найдется не мало сообразительных людей, которые подтвердят мои слова. Теория должна опираться на практику.


вы хотя бы раз взгянули, что выполняет DefWindowProc в ответ на это сообщение. Когда посмотрите, задайте себе вопрос: кто говорит о избыточности? Вы ради самовосхваления дезинформируете молодое поколение. Очень плохо.

Рекурсия - то что вы называете "...избыточен и излишне усложнен..." используется в иерархии наследования классов. Если бы вы внимательно читали мой первый пост, то я об этом сразу и сказал, поэтому она оправдана. Вы ведь даже не понимаете о назначении большинства методов, а судите.

Я не намерен более развивать тему, поскольку самых главных вопросов я так и не услышал, если у остальных они появятся, обащайтесь ко мне непосредственно по аське. Вопрос исчерпан окончательно! 

Из всего вышесказаного лучше всего помогает

Но при этом при перерисовке проц забивается на 100 % (это если хорошо потягать окошко) ...  как от этого лечиться??