Any reason for Edit Controls to flicker?

This is a discussion on Any reason for Edit Controls to flicker? within the Windows Programming forums, part of the Platform Specific Boards category; Originally Posted by idelovski Use five InvalidateRect() calls for each edit control, but not for entire window. I have about ...

  1. #16
    Registered User
    Join Date
    Apr 2008
    Posts
    610
    Quote Originally Posted by idelovski View Post
    Use five InvalidateRect() calls for each edit control, but not for entire window.
    I have about 16 edit controls and i must have 5x16 InvalidateRect() calls...! Is this what you mean...? Oh! i don't need to update the edit controls at all in any case..., i guess doing something called 'clipping' may help but still doing some reading on it! Not sure how it's done yet

    I don't think I have a single case of InvalidateRect() with a NULL param in my entire application because I always invalidate just small parts of the interface than really need repaint.
    I tried
    Code:
     InvalidateRect (hwnd, &rec, FALSE);
    where rec was initialized by GetClientRect function... But doesn't seem to update the client window if i do this

  2. #17
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,428
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #18
    Registered User
    Join Date
    Apr 2008
    Posts
    610

    Working Finally!

    Quote Originally Posted by Elysia View Post
    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
    Last edited by csonx_p; 06-05-2008 at 06:19 AM.

  4. #19
    Registered User
    Join Date
    Mar 2007
    Posts
    142
    Hi,

    I think I wasn't quite clear in my previous posts. I've seen your line "I have a single window which i draw 5 rectangles with lots of text." and I somehow translated that into 5 edit boxes.

    That is why I said you need to call InvalidateRect() five times.

    Sorry. Now I think you only need to call it once, and only for that rectangle that displays results.

  5. #20
    train spotter
    Join Date
    Aug 2001
    Location
    near a computer
    Posts
    3,856
    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.

    Quote Originally Posted by Elysia View Post
    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);

    Quote Originally Posted by Elysia View Post
    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.

    Quote Originally Posted by Elysia View Post
    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.
    "Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
    Friedrich Nietzsche

    "I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
    George Best

    "If you are going through hell....keep going."
    Winston Churchill

  6. #21
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,428
    Not according to MSDN:

    Quote Originally Posted by novacain View Post
    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.
    Quote 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.
    Quote 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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #22
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    UpdateWindow() should not be needed when you don't have a timer with timeout as 1 millisecond.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. My thread stops for no reason
    By lectrolux in forum C Programming
    Replies: 7
    Last Post: 05-21-2003, 07:56 AM
  2. Tab Controls - API
    By -KEN- in forum Windows Programming
    Replies: 7
    Last Post: 06-02-2002, 09:44 AM
  3. Tab controls - MFC (revived)
    By Robert602 in forum Windows Programming
    Replies: 1
    Last Post: 01-22-2002, 11:32 AM
  4. Diff between window controls and dialog controls
    By Garfield in forum Windows Programming
    Replies: 13
    Last Post: 01-18-2002, 04:49 AM
  5. setting default font to draw all further controls with
    By alandrums in forum Windows Programming
    Replies: 0
    Last Post: 12-03-2001, 09:31 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21