title: MFC: How to avoid flickering in child-control updates?
body: <p>I'm been googling for days, and all I'm getting are the same answers, but is not what I want (I will describe what I do not want later).</p>
  
  <p><strong>What I want is:</strong></p>
  
  <ul>
  <li>Say I have a parent dialog that has a few CStatic child controls.  </li>
  <li>The parent dialog uses black as its background when in focus, and gray when not in focus.</li>
  <li>The child static controls simply display text, but its background needs to follow the parent's background color</li>
  </ul>
  
  <p><strong>Problem:</strong></p>
  
  <ul>
  <li>I can get the child-controls to always track the parent's color, however the process of updating the color is slow and causes flicker.</li>
  <li>When I make the dialog to go in focus, I can see the dialog change its color from Gray to Black, then each text controls changing from Gray to Black as well.</li>
  <li>It's slow because it's on an embedded device.</li>
  </ul>
  
  <p>Double buffering would not work because the parent and child has it's own paint routine, so I think it is impossible to share the same buffer.  I've read that WS_EX_COMPOSITE or something works for Vista, but I am on a lower end OS.</p>
  
  <p><strong>What I do not need:</strong></p>
  
  <ul>
  <li>I already understand how to override the background erase routine (that's why I am already getting the controls to update)</li>
  <li>I know how to use CMemDC generally, but as stated, it will not work for my case.</li>
  </ul>
  
  <p>Any ideas, guys?  I'm sure processing speed plays a part, but I strongly believe it is just a technique or setting that I am not doing it right.  I remember my first PC being a 133MHz, but I don't recall Windows 95 updating controls on-by-one when their parent loses focus -- they update almost instantly.  And I don't even have a good video card back then.</p>
  
  <p>Please help.</p>
  
  <p>Additions:
  - I have tried making the BkMode of the controls to be TRANSPARENT, and even use a NULL_BRUSH.  All this together with ON_WM_CTLCOLOR.  What I got is simply a dialog with holes, and in those holes are the control text.  In other words, instead of the control's background simply weren't drawn (as expected from NULL_BRUSH), but that area wasn't covered by the dialog's paint job either.
  - I am thinking of removing WS_CLIPCHILDREN, but I believe that will cause the controls to be drawn over anyway, so, flicker again.</p>