Thread: Any reason for Edit Controls to flicker?

Are those coordinates relative to the window's client area or the actual control's client area?
(Hint: if the top and left are 0, then it's the control's.)
Because InvalidateRect takes coordinates relative to the window whose handle you pass. So if you pass it for your window, then you must pass coordinates where your controls are located inside the dialog.

If you just want to update specific controls, you can just call invalidate and pass the handle for those controls.

Originally Posted by Elysia

Are those coordinates relative to the window's client area or the actual control's client area?
(Hint: if the top and left are 0, then it's the control's.)
Because InvalidateRect takes coordinates relative to the window whose handle you pass. So if you pass it for your window, then you must pass coordinates where your controls are located inside the dialog.

If you just want to update specific controls, you can just call invalidate and pass the handle for those controls.

Clipping regions was the solution to avoid flickering, together with double buffering.. wow! What a learning experience... Thanx Elysia for being patient with me. You form Big part of what i've learnt this past few weeks, not to forget Mats and, of cause every else who contributed. I like learning and the only way i have in the past is to ask... I guess some people don have patience with me but you guys have...

Well, talk to you when i have a new interesting problem

FYI...

Code:

InvalidateRgn (hwnd, rgnRsl, FALSE);

Only invalidates clipped regions instead of InvalidatedRect...

First, had to select all five rectangles into memory DC by using CreateRectRgn..

Code:

 // Create clipping regions for all five rectangles
rgnRdrAnt = CreateRectRgn(aptRect[0].x, aptRect[0].y, aptRect[1].x, aptRect[1].y); 
rgnTrnRcv = CreateRectRgn(aptRect[2].x, aptRect[2].y, aptRect[3].x, aptRect[3].y); 
rgnTrgt = CreateRectRgn(aptRect[4].x, aptRect[4].y, aptRect[5].x, aptRect[5].y); 
rgnGenPar = CreateRectRgn(aptRect[6].x, aptRect[6].y, aptRect[7].x, aptRect[7].y); 
rgnRsl = CreateRectRgn(aptRect[8].x, aptRect[8].y, aptRect[9].x, aptRect[9].y); 

// .. then combine them into a single rectange
CombineRgn(cmbndRngs, rgnRdrAnt, rgnTrnRcv, RGN_OR);
CombineRgn(cmbndRngs, rgnTrgt, cmbndRngs, RGN_OR);
CombineRgn(cmbndRngs, rgnGenPar, cmbndRngs, RGN_OR);
CombineRgn(cmbndRngs, rgnRsl, cmbndRngs, RGN_OR);

// lastly, add to off-screen buffer
SelectClipRgn(memDC, cmbndRngs);

then only repainted the last rectangle (the results one) ... Nice exercise

Did you try processing WM_ERASEBKGND msgs (just return non zero)?

This stops alot of the flicker. As it prevents continual redrawing of the edits.

Originally Posted by Elysia

The way you call InvalidateRect will make it pretty useless because it will invalidate the ENITRE client are, including your other controls, forcing them to update, as well.

As the WM_PAINT handler does not use the update region in the BitBlt() (the paint handler redraws the entire area anyway) there will be no change adding the Rect to the InvalidateRect() call.

You would also have to use the update Rect from the PAINTSTRUCT in the BitBlt() call (ie only draw the invalidated rect, not the entire BMP in the paint.

BitBlt(hdc, pntS.left, pntS.top, pntS.right-pntS.left ,pntS.bottom-pntS.top ,msmDC ,pntS.left ,pntS.top ,SCRCOPY);

Originally Posted by Elysia

InvalideRect puts the specified area into the invalidated region which is repainted the next time a WM_PAINT message is received by the program. Windows checks periodically if the invalidate queue is empty and if not, posts a WM_PAINT message. Messages that are posted is queued in the message queue, waiting there until the program handles it.

My understanding is different. InvalidateRect() generates the WM_PAINT msg.

WM_PAINT msgs are low priority (as with WM_TIMER) in the OS queue. Paint msgs are concatinated within the queue, and droped to the bottom if higher priority msgs are present.

Originally Posted by Elysia

UpdateWindow on the other hand, forces the window to repaint by sending a WM_PAINT message and blocking until it is processed. It does not queue it, so likely it will incur a performance hit.

UpdateWindow() causes the WM_PAINT msg to be posted to the app queue, not the OS queue. It is not a blocking msg like SendMesage() which must be processed before the call can complete or times out (default at 5 seconds).

Usually it is a perfomance increase not hit.

Not according to MSDN:

Originally Posted by novacain

My understanding is different. InvalidateRect() generates the WM_PAINT msg.

WM_PAINT msgs are low priority (as with WM_TIMER) in the OS queue. Paint msgs are concatinated within the queue, and droped to the bottom if higher priority msgs are present.

Originally Posted by MSDN

The InvalidateRect function adds a rectangle to the specified window's update region. The update region represents the portion of the window's client area that must be redrawn.

The invalidated areas accumulate in the update region until the region is processed when the next WM_PAINT message occurs or until the region is validated by using the ValidateRect or ValidateRgn function.

The system sends a WM_PAINT message to a window whenever its update region is not empty and there are no other messages in the application queue for that window.

In other words, it does not send WM_PAINT--the system does when it thinks the time is right.

UpdateWindow() causes the WM_PAINT msg to be posted to the app queue, not the OS queue. It is not a blocking msg like SendMesage() which must be processed before the call can complete or times out (default at 5 seconds).

Usually it is a perfomance increase not hit.

Originally Posted by MSDN

The UpdateWindow function updates the client area of the specified window by sending a WM_PAINT message to the window if the window's update region is not empty. The function sends a WM_PAINT message directly to the window procedure of the specified window, bypassing the application queue. If the update region is empty, no message is sent.

In other words, it's sent directly and not posted.

UpdateWindow() should not be needed when you don't have a timer with timeout as 1 millisecond.