Redraw problem with CRichEditCtrl and CListCtrl edges
Hi!
We are making a MFC app with VS2005 (C++).
In the GUI, sometimes the edges of certain controls (a CRichEditCtrl and a CListCtrl) are not redrawn properly.
Instead of the 3D effect border, there is no border. So the CRichEditCtrl is drawn as a simple white rectangle
on the gray background. Same with the CListCtrl (the border is missing).
Covering the app windows with some other window, then moving it away, makes the missing borders draw. But only in the parts, that were covered. The rest is still missing.
I am not sure how to reproduce this, so I can not make a screenshot. Hopefully this is a well known programmer error Wink
Re: Redraw problem with CRichEditCtrl and CListCtrl edges
I guess you're updating your progress bar in a tight loop without letting Windows repaint your window. Something like InvalidateRect, UpdateWindow or RedrawWindow has to be done periodically.
Re: Redraw problem with CRichEditCtrl and CListCtrl edges
What j66st wants to know is, are you looping in the same thread as your message loop?
If you have a long task that needs to be done, and you want the UI to update properly, then you will need to split off the task into a different thread so windows is able to redraw when necessary.
Or you can manually redraw the UI, but bypassing the message loop is never a very good idea.
Re: Redraw problem with CRichEditCtrl and CListCtrl edges
Originally Posted by xerces8
No.
The work is done in a separate thread.
Funny thing is, that the problem is only with edges/borders. All the rest is drawn properly.
That indicates indeed that the message loop (in the user interface thread) is stuck, and that paint requests by windows are not honoured. The painting of the progress bar itself is done directly by some GDI calls invoked from your worker thread, that's why that part is updated.
Re: Redraw problem with CRichEditCtrl and CListCtrl edges
This is all greek to me. :-p
What usually happens is, that the app windows is covered by some other window, then that window is removed (minimized or closed, or our program is called to foreground) and the most of the GUI is redrawn, except borders.
Even if the message loop is busy, shouldn't the repaint event be honored when the busy code ends ?
Is some message getting lost ?
(note: the problem happens rarely, like once in 20 tries, otherwise the GUI is redrawn properly)
Last edited by xerces8; May 20th, 2009 at 09:33 AM.
Re: Redraw problem with CRichEditCtrl and CListCtrl edges
Well, there are many ways to mess things up
The best thing you can do is:
Keep ALL user interface calls in your main thread. If you want to update the progress bar from your worker thread, just post a message to your main thread and let it send the message to the control. In a single-core PC you should have some idle time (for example a periodic Sleep call) to give the main thread time to do its thing. Paints have low priority.
You can try to fix it and force a repaint by calling RedrawWindow, but with a proper design this should not be necessary.
Re: Redraw problem with CRichEditCtrl and CListCtrl edges
The project is finished
I would just add, that the problem appears right after program start before the worker thread is created. The program window appears and wait for some user input, nothing else.
I noticed similar redraw problems in Visual Studio IDE itself, so I guess this is some general MS problem....
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.
Reply With Quote
Originally Posted by xerces8
