3

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).

What I want is:

  • Say I have a parent dialog that has a few CStatic child controls.
  • The parent dialog uses black as its background when in focus, and gray when not in focus.
  • The child static controls simply display text, but its background needs to follow the parent's background color

Problem:

  • 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.
  • 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.
  • It's slow because it's on an embedded device.

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.

What I do not need:

  • I already understand how to override the background erase routine (that's why I am already getting the controls to update)
  • I know how to use CMemDC generally, but as stated, it will not work for my case.

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.

Please help.

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.

Hogan
  • 69,564
  • 10
  • 76
  • 117
Ryuu
  • 779
  • 11
  • 22
  • I don't know anything abut MFC so excuse me if this isn't a relevant question, but is it not possible to just set the child controls to have a transparent background? – Jamie Dixon Oct 10 '11 at 14:14
  • Ah, yes, I have thought of that as well. I will update my initial post to reflect the problems I had with it. – Ryuu Oct 10 '11 at 14:18
  • Which version of MFC and Visual Studio are you using? – ChrisBD Oct 10 '11 at 14:21
  • Basically, I don't have problems making the controls update its background color when necessary. The problem lies with the speed and sequence of updates (parent -> child1 -> child2 -> etc) that is causing the flickering. I do have a solution, which is to simply override the dialog's OnPaint, and use DrawText. It works perfectly using TRANSPARENT as the BkMode, but I want a solution that covers the usage of child controls. I can't be drawing everything everytime ... no point of using MFC then. – Ryuu Oct 10 '11 at 14:30

3 Answers3

1

Did you try SetRedraw()? You can call SetRedraw( FALSE) for child windows so they don't update themselves every time you change the parent and when parent editing is complete you can finally call SetRedraw(TRUE) for childs - and perhaps invalidate at that time so they update themselves only once.

zar
  • 11,361
  • 14
  • 96
  • 178
0

Have you tried to override WM_CTLCOLOR? Check out my answer to this post

Note: You can set the background color of the static control by using pDC->SetBkColor and returning a brush with the color you want.

Community
  • 1
  • 1
djeidot
  • 4,542
  • 4
  • 42
  • 45
  • Hi djeidot. Yeah, I used all that, and it works in changing the background color. But the question is how to avoid flickering, not how to change the color. The process of "parent updates first, then individual childs get updated later" is too slow on my platform. – Ryuu Oct 10 '11 at 14:27
  • The idea of `WM_CTLCOLOR` was to avoid using `WM_PAINT` or `WM_ERASEBKGND` which are likely to cause flickering. You should know that you can also change the dialog background color with `WM_CTLCOLOR`. – djeidot Oct 10 '11 at 15:01
0

I've done that before by overriding the erase background of the dialog. Then, instead of calling the default function, you prepare are region, traverse all the children of the dialog and clip out their bounds from the region. At the end, you fill the rectangle with the dialog background color.

Basically, the idea is to erase only where there are no controls.

This would would but i'm not sure if there is a better way to do it. Like the 'clip children' option, or i believe there were style for double buffering.

The Dark Brainer
  • 694
  • 6
  • 16