Controls are flicker madly on resize. I'm trying double buffering but I still ...

[JohnCz]

Yes, please post ypur code.

[MikeAThon]

Also if I misunderstood your post please let me know .

I think it's possible that you might have misunderstood. As requested by JohnCz, please post code. Not the actual code of your project, but simple code that demonstrates the flicker that you are encountering.

Generally speaking, with no special effort at all, a resizable dialog will not show any appreciable flicker until there are maybe 50-80 controls on it simultaneously. I don't think you have that many controls. And note that I said that "no special effort" is required for flicker-free performance. Just ensure that WS_CLIPCHILDREN is set. So the fact that you are seeing significant flicker, and the fact that WS_CLIPCHILDREN made it worse, tell me that there is something wrong with the overall architecture, fundamentally.

You state that you are using "actual" controls ("actual" meaning that the controls have their own WndProcs that are probably the default WndProcs supplied by Windows). If so, you are somehow overriding the WM_PAINT messages sent to the controls themselves, and somehow painting the controls in a doulbe-buffering mechanism in the WM_PAINT handler for the parent dialog. Please let us know (show the code) if you are using some abomination like a SendMessage of WM_PAINT to the control from within the WM_PAINT handler of the dialog, like so:

// from the WM_PAINT handler of the parent dialog
// pseudo-code

hdc = BeginPaint()
hdcMem = create memory device context

SendMessage( hwndControl_1, WM_PAINT, hdcMem, 0L );
SendMessage( hwndControl_2, WM_PAINT, hdcMem, 0L );


BitBlt( hdcMem into the hdc );

ReleaseEverything
EndPaint();

If you are doing something like this, then it's not a wonder that there is flicker.

Mike

[Senith]

I think it's possible that you might have misunderstood. As requested by JohnCz, please post code. Not the actual code of your project, but simple code that demonstrates the flicker that you are encountering.

Generally speaking, with no special effort at all, a resizable dialog will not show any appreciable flicker until there are maybe 50-80 controls on it simultaneously. I don't think you have that many controls. And note that I said that "no special effort" is required for flicker-free performance. Just ensure that WS_CLIPCHILDREN is set. So the fact that you are seeing significant flicker, and the fact that WS_CLIPCHILDREN made it worse, tell me that there is something wrong with the overall architecture, fundamentally.

You state that you are using "actual" controls ("actual" meaning that the controls have their own WndProcs that are probably the default WndProcs supplied by Windows). If so, you are somehow overriding the WM_PAINT messages sent to the controls themselves, and somehow painting the controls in a doulbe-buffering mechanism in the WM_PAINT handler for the parent dialog. Please let us know (show the code) if you are using some abomination like a SendMessage of WM_PAINT to the control from within the WM_PAINT handler of the dialog, like so:

// from the WM_PAINT handler of the parent dialog
// pseudo-code

hdc = BeginPaint()
hdcMem = create memory device context

SendMessage( hwndControl_1, WM_PAINT, hdcMem, 0L );
SendMessage( hwndControl_2, WM_PAINT, hdcMem, 0L );


BitBlt( hdcMem into the hdc );

ReleaseEverything
EndPaint();

If you are doing something like this, then it's not a wonder that there is flicker.

Mike

Well what you said so far is pretty much true other then using SendMessage within the WM_PAINT.

Also I somehow manage to fix most of the flickering within my control other then the frame. I'm using WS_CLIPCHILDREN now on my main form as without it would cause all of my controls to flicker.

What ever I did it allowed the CLIPCHILDREN style to work correctly now from the looks of it

Also I read on another forum that you should never send a WM_PAINT message to a control using SendMessage other then windows. So I haven't done that.

Now for the WM_PAINT of my control for the WndProc is as fallows:

    case WM_ERASEBKGND:
      return true ;
    break;
   
    case WM_PAINT:

        HDC          hdcMem;
        HBITMAP      hbmMem;
        HANDLE       hOld;
        PAINTSTRUCT  ps;
        HDC          hdc;
        RECT Temp_Rect;


        RECT Menu_Rect;
        MENUINFO mi;
        GetMenuInfo(GetMenu(hwnd),&mi);    
        RECT Client;
        GetClientRect(hwnd,&Client);    
        RECT Rebar_Rect;
        GetWindowRect(hwnd,&SSMAIN_RECT);
        GetWindowRect(SSMAIN_REBARWINDOW,&Rebar_Rect);
        SSMAIN_WIDTH=SSMAIN_RECT.right-SSMAIN_RECT.left;
        SSMAIN_HEIGHT=SSMAIN_RECT.bottom-SSMAIN_RECT.top;
        Temp_Rect=SSMAIN_RECT;        
        
        hdc = BeginPaint(hwnd, &ps);       
        hdcMem = CreateCompatibleDC(hdc);
        hbmMem = CreateCompatibleBitmap(hdc, SSMAIN_WIDTH,SSMAIN_HEIGHT);
        hOld   = (HBITMAP)SelectObject(hdcMem, hbmMem); 
        
        cout<<"PAIN: WP TOP: "    <<SSMAIN_RECT.top<<endl;
        cout <<"SSMAIN Client bottom:"<<Client.bottom<<endl;        
        cout<<"2WP Explorer Rect: L:T:R:B"<<SSMAIN_EXPLORERWINDOW_RECT.left<<":"<<SSMAIN_EXPLORERWINDOW_RECT.top<<":"<<SSMAIN_EXPLORERWINDOW_RECT.right<<":"<<SSMAIN_EXPLORERWINDOW_RECT.bottom<<endl;
        
        FillRect(hdcMem, &Client, (HBRUSH) (COLOR_WINDOW+7));        
        BitBlt(hdc, 0, 0,  SSMAIN_WIDTH, SSMAIN_HEIGHT, hdcMem, 0, 0, SRCCOPY);    
        
        SelectObject(hdcMem, hOld);
        DeleteObject(hbmMem);
        DeleteDC(hdcMem); 
        EndPaint(hwnd, &ps);
    break;

Also so far I'm still new to the double buffer procedure so I've been looking around sites to find more info out about it and used the basic code below and adopted it from their.

WM_PAINT:
        hdc = BeginPaint(hwnd, &ps);       
        hdcMem = CreateCompatibleDC(hdc);
        hbmMem = CreateCompatibleBitmap(hdc, SSMAIN_WIDTH,SSMAIN_HEIGHT);
        hOld   = (HBITMAP)SelectObject(hdcMem, hbmMem); 

//... Code that I added on my self

        SelectObject(hdcMem, hOld);
        DeleteObject(hbmMem);
        DeleteDC(hdcMem); 
        EndPaint(hwnd, &ps);
break;

If you guys need anything else please let me know.

[Senith]

OK guys now I know why the frame is not working correctly.

Here the thing.

When I turn the frame back into a button and run the program it doesn't flicker at all.

When I turn it back into a frame(Group Box, button) its drawing just the frame and leaves the background transparent so since the background is being clipped by the main window, it shows the frame with a transparent background within the clip region which you all know never updates.

So this means that anything that will cover that area will stay their as it is not being erased which is a good thing.

However! its not good when the frame which is a button is drawing its background transparent.

I need it to have a main background color that fills it without replacing the main frame in this case will just be one solid background on the frame without the frame borders. This I do not want

So the thing is now how can I draw a non transparent background within the frame that does not replace the frame border region?

Thanks and also the frame(button does not have the WS_EX_TRANSPARENT style set)

Thanks again everyone!

[Senith]

ok as I feared when you use the BS_GROUPBOX it will automatically set a transparent background which I can't have as the parent clips the area behind it.

So I'm just going to go ahead and draw the control my self. Should be all that hard.

So thank you all for helping me out with this.

really appreciate it!

[MikeAThon]

As your code is written, double buffering is not a cause of your problem and is a complete red-herring.

Which all of us would have been able to tell you immediately, without all the back-and-forth, had you responded to our request for a minimum code sample that demonstrates your problem.

As for your double-buffering code, it does nothing and should be eliminated.

Good luck,
Mike

[Senith]

As your code is written, double buffering is not a cause of your problem and is a complete red-herring.

Which all of us would have been able to tell you immediately, without all the back-and-forth, had you responded to our request for a minimum code sample that demonstrates your problem.

As for your double-buffering code, it does nothing and should be eliminated.

Good luck,
Mike

Ok thanks Mike.

I'll remove the double buffer from my WM_PAINt, Better yet I'll remove the whole WM_PAINT.

I think when I tried that last time though and not returning WM_ERASEBKGND to true I think it did cause flicker again.

I can't remember so I'll let you all know what happens.

Also I'm still very new to the whole GDI process.

I still have to manually take over WM_PAINT for my button control or else it will draw the frame with a transparent background which I can't have. As I stated before the clip children clips the rgn behind it. So with the frame bg being transparent I can't have that.

So I have to draw the frame using GDI which I already have working.

Anyways thanks everyone for you help

I really do appreciate it ^^