Thread: Any reason for Edit Controls to flicker?

  1. #1
    Registered User
    Join Date
    Apr 2008
    Posts
    610

    Any reason for Edit Controls to flicker?

    I know i have a long thread on this flickering topic and am not trying to drag it here but have a separate question altogether, or rather looking for reasons rather than solutions... Edit controls are created using CreateWindowEx(..., "edit",...); And this is done in WM_CREATE, so i find it strange that they would flicker because InvalidateRect() doesn't affect WM_CREATE, only WM_PAINT... Any ideas..?

  2. #2
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    When the edit controls are redrawn too fast, they flicker. This applies to all controls and text and text drawings.
    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. #3
    Registered User
    Join Date
    Apr 2008
    Posts
    610
    Quote Originally Posted by Elysia View Post
    When the edit controls are redrawn too fast, they flicker. This applies to all controls and text and text drawings.
    I'm not redrawing the edit controls as i have mentioned that they are created in WM_CREATE... That's about the only place they appear in the code, unless windows does re-drawing somewhere by default.. Or i'm missing some info on how objects are drawn on windows

  4. #4
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    You have to consider whether or not children are being clipped in the parent - how/when the parent paints - and other factors.

    If you post a small flickering example, we can probably tell you why and how to fix it.

    gg

  5. #5
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by csonx_p View Post
    I'm not redrawing the edit controls as i have mentioned that they are created in WM_CREATE... That's about the only place they appear in the code, unless windows does re-drawing somewhere by default.. Or i'm missing some info on how objects are drawn on windows
    But WM_CREATE and WM_PAINT are two different things.
    Painting is applied to all controls and regions that needs to be repainted.
    They need to be repainted when some pixel inside its client area has the wrong color. Say you move a window over your edit, and then move it out. On that pixel, it would now have the color of the dialog you moved over, so the edit needs to be repainted.

    And if you do this too much, it will flicker.
    And when you do invalidate, you must take into account whether it will clip or repaint the child windows, as well. Windows is a complex beast, unfortunately, so I don't know exactly when and how it occurs.
    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.

  6. #6
    Registered User
    Join Date
    Apr 2008
    Posts
    610
    Quote Originally Posted by Codeplug View Post
    You have to consider whether or not children are being clipped in the parent - how/when the parent paints - and other factors.
    And when you do invalidate, you must take into account whether it will clip or repaint the child windows, as well
    I have a single window, what do you mean by child? And the flickering is happening without me resizing/dragging the window... Just by calling InvalidateRect()...

    Can someone explaining further on the parent clipping the child anyway! These terms sounds easy for someone who has worked on Win Programming long enough...thanx

  7. #7
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    As we told you...
    Each window typically has a parent. So to that parent, your window is a child window.
    Every control you add to your window is also a window, thus they are children on your actualy dialog/window.
    So when you invalidate, it may cause your windows children to also be invalidated and need repainting.
    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.

  8. #8
    Registered User
    Join Date
    Apr 2008
    Posts
    610
    Quote Originally Posted by Elysia View Post
    As we told you...
    Each window typically has a parent. So to that parent, your window is a child window.
    Every control you add to your window is also a window, thus they are children on your actualy dialog/window.
    So when you invalidate, it may cause your windows children to also be invalidated and need repainting.
    So the word 'window' doesn't necessary mean the normal rectangle with minimize/close/restore and title bar... Or dialog boxes. It may be a button/edit control/Static Control... But then you right cause all these are created with CreateWindow()... My stupidity there...

    Just an update... I've commented every single code which draws something to the memory DC. I then called bitblt () to paint on screen an empty DC so the output would just be the edit controls (no rectangles & text)... The edit controls still flickers meaning just repainting with with bitblt causes the flickering because the moment i comment out bitblt, no flickering occurs. Am very close to giving up but something tells me it';s a small thing....

  9. #9
    Registered User
    Join Date
    Apr 2008
    Posts
    610

    rephrasing my problem

    How about i rephrase my problem, perhaps may bring some light

    I have a single window which i draw 5 rectangles with lots of text. 4 of these rectangles have at least each 2 edit controls for user input. The fifth rectangle is to display results calculated from the edited controls. I use the timer to update the window that whenever the user enters new data on edit controls, the results are immediately calculated.

    Problem: Well, the initial compilation of the program produced terrible window flickering (could see a huge flickering from bottom up) but managed to remove that by setting wcx.hbrBackground to NULL when creating the window and also returning non-zero to WM_ERASEBKGND... The flickering is now happening on the edit controls only, not the entire window. And after a minute or so, the text display start loosing the font i used (non-bold & italics), every text suddenly becomes bold and no-italics. The borders of the rectangle also become thiner, noticed i also loose one rectangle...Also, if i leave this for a little longer, the window itself repaints badly and looses the title bar (or fades the entire blue bar), Infact, my entire screen fades some icons on the windows Start Menu bar if i let this run forever... To close my application i would have to do CNTRL+ALT+DEL. To me this seems more like memory issues (overloading buffers or something). As i said, i display a lot of text (declared as TCHAR) using TextOut() function and use CreateFont() to set my text fonts. If i comment out all my displaying of text leaving only the rectangles & edit controls to paint, i still do get flickering but not the changing of fonts and borders, and the title bar stays for longer.

    All of this is after i have attempted doing the off-screen DC with bitblt... Am really stuck as to what the problem may be... Here's some of the code. It's a larger program so can't post everything here!

    Code:
    	case WM_CREATE:
    		{	   
    			GetClientRect(hwnd, &clientRECT);
    
    			// Client area width & height
    			cScreenX=GetSystemMetrics(SM_CXSCREEN);
    			cScreenY=GetSystemMetrics(SM_CYSCREEN);
    
    			// Client Device Context
    			hDC=GetDC(hwnd);
    			memDC = CreateCompatibleDC(hDC);
    
    			// Memory Device Context
    			hBitmap = CreateCompatibleBitmap(hDC,cScreenX,cScreenY);
    			hOldBitmap = SelectObject(memDC,hBitmap);
    
    			// Paint screen background on mem DC grey 
    			hBrush = CreateSolidBrush( RGB(0xD3, 0xD3, 0xD3) );
    			FillRect(memDC, &clientRECT, hBrush);
    			DeleteObject(hBrush);
    
    			ReleaseDC(hwnd,hDC);
    
    			/* Screen refresh time */
    			SetTimer(hwnd, IDT_REFRESH, REFRESHTIME, NULL); 
    
    			/* Create edit controls */
    			EditBoxes(hwnd, cs);
    
    			/* Create radio buttons */
    			RadioButtons(hwnd, cs);
    		}
    		return 0;
    
    	case WM_PAINT:
    		{
    			hdc = BeginPaint(hwnd, &pntS);
    			BitBlt(hdc, 0, 0, cScreenX, cScreenY, memDC, 0, 0, SRCCOPY);			
    			EndPaint(hwnd, &pntS);
    		}
    		return 0;
    
    	case WM_TIMER: 
    		{
    			/* Begin rendering Data on Mem DC */
    
    
    // Displaying text 
    	PrintText(hwnd, rdrTrans_recv[FREQ], initRecArea(395,45,0,0), hdc,  
    		fntClr[1].boldStyle, fntClr[0].bkgrngColor[0], fntClr[0].txtColor, fntClr[1].italicStyle);
    
    			// Retrieve data, calculate & display 
    			output = ProcessData(hwnd);
    			DisplayResults(hwnd, memDC, &output, rsltFont);
    
    			InvalidateRect (hwnd, NULL, FALSE);
    			UpdateWindow(hwnd);
    		}
    		break;
    
    
    // PrintText function
    // Display text on screen
    void PrintText(HWND hWnd, TCHAR txt[], RECT rc, HDC hDC, DWORD fnWeight, 
    			   COLORREF bkgrndClr, COLORREF txtColor, BOOL italics)
    {
    	long lfHeight=-MulDiv(12, GetDeviceCaps(hDC, LOGPIXELSY), 72);
    	HFONT font=CreateFont(lfHeight, 0, 0, 0, fnWeight, italics, 
    		0, 0, 0, 0, 0, 0, 0, _T("Times New Roman"));
    
    	HGDIOBJ hDefFont=SelectObject(hDC, font);
    	
    	SetBkColor(hDC, bkgrndClr);
    	SetTextColor(hDC, txtColor);
    
    	TextOut(hDC, rc.left, rc.top, txt,(int)_tcslen(txt));
    
    	SelectObject(hDC, hDefFont);
    	DeleteObject(hDefFont);
    }

    As you may noticed, this code attempts to use Memory DC

  10. #10
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,981
    >> The flickering is now happening on the edit controls only,
    Create the parent with WS_CLIPCHILDREN - that may help.

    Sounds like you've got more issues to deal with than just flickering ....

    >> DeleteObject(hDefFont);
    There's one of em. You want to delete "font" there.

    gg

  11. #11
    Registered User
    Join Date
    Apr 2008
    Posts
    610
    Quote Originally Posted by Codeplug View Post

    >> DeleteObject(hDefFont);
    There's one of em. You want to delete "font" there.

    gg
    Wow! Solved my memory leakage problem... Font is now stable... How do i pay the bill!

  12. #12
    Registered User
    Join Date
    Mar 2007
    Posts
    142
    InvalidateRect (hwnd, NULL, FALSE) is probably responsible for the flickering. Try to remove it and see what happens. If it's no good put it back, but remove UpdateWindow(hwnd).
    Last edited by idelovski; 06-05-2008 at 03:03 AM.

  13. #13
    Registered User
    Join Date
    Apr 2008
    Posts
    610
    Quote Originally Posted by idelovski View Post
    InvalidateRect (hwnd, NULL, FALSE) is probably responsible for the flickering. Try to remove it and see what happens. If it's no good put it back, but remove UpdateWindow(hwnd).
    And how do i repaint?

  14. #14
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    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.
    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.

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

  15. #15
    Registered User
    Join Date
    Mar 2007
    Posts
    142
    And how do i repaint?
    Good question!

    Now I see that you're not doing much in WM_PAINT. Only background blitting?

    Then, use five InvalidateRect() calls for each edit control, but not for entire window. 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.

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, 12:32 PM
  4. Diff between window controls and dialog controls
    By Garfield in forum Windows Programming
    Replies: 13
    Last Post: 01-18-2002, 05: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, 10:31 PM