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

Thanks for any hint,
David

Quote:

---

Originally Posted by xerces8

I am not sure how to reproduce this, so I can not make a screenshot.

---

So... what's the problem?

The problem is that this happens every other day. And it will happen on the customers system too.

Here is a screenshot attached.

The progress bar has the border missing on the left side, while the right end has it.
There was a windows covering the left part, then it was closed.

Anyone ? :(

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.

No, the progress bar is updated once or twice per second. Or not at all.
Also other elements (like a RichEdit) also have the same problem.

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.

Kelly

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.

Quote:

---

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.

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)

Another screenshot.
This time is seems only the background was not drawn.

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.

I would ask that you post the project, or some similar one to reproduce it here so we can test on our own PCs and see whats cooking :)

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