Repaint failure

I'm using VC++ 6 on Win2k, and I am testing on XP and Vista for compatibility problems. My app has a graphic window which is not repainting properly when my app has lost focus and other windows are dragged across it. When my app is topmost, there is no problem. When a child dialog dragged across, there is no problem.

Since the repaint does occur (albiet corrupted), I know WM_PAINT is being handled. What is baffling to me is that the problem only happens in XP and Vista, not Win2K.

I am drawing to a buffer in memory and blitting to the screen:

Code:

---

case WM_PAINT:
        dc = BeginPaint(hWsbox, &ps);
        SelectObject(dc, hBitmap);
        BitBlt(dc, 0, 0, selarr_wid, selarr_hgt,
                sdc, 0, scroll ? si.nPos * (SEL_RY + fhgt) : 0, SRCCOPY);
        EndPaint(hWsbox, &ps);
        break;

---

Can someone give me a clue?

I experienced similar problems and my (not the best I think) solution was to add an InvalidateRect() like this:

Code:

---

case WM_PAINT:
        InvalidateRect(hWsbox, NULL, TRUE);
        dc = BeginPaint(hWsbox, &ps);
        SelectObject(dc, hBitmap);
        BitBlt(dc, 0, 0, selarr_wid, selarr_hgt,
                sdc, 0, scroll ? si.nPos * (SEL_RY + fhgt) : 0, SRCCOPY);
        EndPaint(hWsbox, &ps);
        break;

---

Interesting idea. It seems redundant to put InvalidateRect() in the paint handler, since the rect is already invalid in order for the WM_PAINT to be sent.

But I tried that, and it actually prevents the corruption problem, at the expense of horrendous flicker from the background erasure. I tried it both ways, erase flag true or false, and it doesn't matter, it flickers badly both ways.

Thanks for the idea, it may lead to something that works.

I forgot to say I prevent or alleviate the flicker problem with

Code:

---

      case WM_ERASEBKGND:
        return(1); // Prevent erasing the background to reduce flickering
        break;

---

Quote:

---

Code:

---

      case WM_ERASEBKGND:
        return(1);

---

---

Can't do that or the rest of the window will have no background. There is an area with buttons that needs the background. I discovered that by trying it a while ago.

I've been trying stuff, and have arrived at code that has no repaint corruption on Vista now, as well as Win2K. XP shows some occasional flickering in the bitmap window, but not horrendous, and no corruption. So maybe I'll just live with it for now.

Code:

---

        case WM_ACTIVATE:
                if (LOWORD(wParam) != WA_INACTIVE) InvalidateRect(hWnd, 0, 0);
                break;

        case WM_PAINT:
                if (GetActiveWindow() != hWnd) InvalidateRect(hWnd, &re, 0);
                dc = BeginPaint(hWsbox, &ps);
                SelectObject(dc, hBm);
                BitBlt(dc, ps.rcPaint.left,
                        ps.rcPaint.top,
                        ps.rcPaint.right - ps.rcPaint.left,
                        ps.rcPaint.bottom - ps.rcPaint.top,
                        sdc, ps.rcPaint.left,
                        ps.rcPaint.top + (scroll ? si.nPos * (SEL_RY + fhgt) : 0),
                        SRCCOPY);
                EndPaint(hWsbox, &ps);
                break;

        case WM_ERASEBKGND:
//                if (GetActiveWindow() != hWnd) return 1;
                break;

---

1. You forget to deselect the hBitmap from the dc at the end. That will create problems for sure.

2. The fact that WM_PAINT is sent doesn't mean necessarily that it will repaint the whole window. It will repaint only the invalid region of the window. You don't need to bother about that, the OS will properly invalidate any area in need to be repainted.

3. A few questions:
a. Are you sure the right bitmap is selected all the time in the sdc ?
b. Is the bitmap containing the right image ?
c. Are coordinates and sizes properly calculated ?
d. Is your bitmap large enough to cover the whole window ?

4. Never call Invalidate from the inside of the WM_PAINT message handler.

5. Are you sure that you comply with all the requirements to deal with graphic functions ?
- Each SelectObject must have a pair that deselects that object when no longer needed
- Each bitmap creation function must have a DeleteObject pair to delete it when no longer needed
- Each dc created must be deleted/released when no longer necessary.
DC function pairs:
BeginPaint with EndPaint
GetDC with ReleaseDC
CreateCompatibleDC with DeleteDC

When deleting a dc, none of the objects created by you must be left selected in it. (That's what you did wrong here. And probably there are more in the code you didn't post.)

You should have:

Code:

---

BeginPaint....
.....
HBITMAP hBitmapOld = SelectObject(dc, hBitmap);
.....

SelectObject(dc, hBitmapOld);
EndPaint...

---

Failure to comply with all these requirements will lead to serious problems. Just creating graphic objects and not disposing them properly will fill all the GDI memory with useles objects. You will run out of the GDI memory with unpredictable results. Anyway here's a prediction: subsequently all graphic operations will fail, you window will start displaying graphics "borrowed" from the overlapping windows.

Thanks for your ideas.

Quote:

---

Originally Posted by srelu

1. You forget to deselect the hBitmap from the dc at the end. That will create problems for sure.

---

Forget? No. What is "deselect"? There is no other bitmap existing to "replace" the one containing the window's image. Are you saying I should have a "null" bitmap handle to replace hBm when painting is done?

Quote:

---

2. The fact that WM_PAINT is sent doesn't mean necessarily that it will repaint the whole window. It will repaint only the invalid region of the window. You don't need to bother about that, the OS will properly invalidate any area in need to be repainted.

---

Yes, I know this.

Quote:

---

a. Are you sure the right bitmap is selected all the time in the sdc ?
b. Is the bitmap containing the right image ?
c. Are coordinates and sizes properly calculated ?
d. Is your bitmap large enough to cover the whole window ?

---

a) Yes, there is only one.
b) Absolutely.
c) Yes.
d) Yes.

Quote:

---

4. Never call Invalidate from the inside of the WM_PAINT message handler.

---

I have never done this before, but out of desperation, I had to try different things. This seemed to eliminate the ghost trails (in trade for intermittent flickering).

Quote:

---

5. Are you sure that you comply with all the requirements to deal with graphic functions ?

---

AFAIK.

Quote:

---

- Each SelectObject must have a pair that deselects that object when no longer needed

---

I have never heard if this in 15 years of GDI programming. I wonder why not.

Quote:

---

- Each bitmap creation function must have a DeleteObject pair to delete it when no longer needed
- Each dc created must be deleted/released when no longer necessary.
DC function pairs:
BeginPaint with EndPaint
GetDC with ReleaseDC
CreateCompatibleDC with DeleteDC

---

Understood. I always do this. I typically use NuMega Bounds Checker to tell me if I am missing any DeleteXX calls.

Quote:

---

When deleting a dc, none of the objects created by you must be left selected in it. (That's what you did wrong here. And probably there are more in the code you didn't post.)

---

Again, I have never heard of this. Do you have a link to info that says this is so?

Quote:

---

Failure to comply with all these requirements will lead to serious problems. Just creating graphic objects and not disposing them properly will fill all the GDI memory with useles objects. You will run out of the GDI memory with unpredictable results. Anyway here's a prediction: subsequently all graphic operations will fail, you window will start displaying graphics "borrowed" from the overlapping windows.

---

I have never had any GDI problems in many years of intermittent Windows programming. This is the first instance of "repaint failure", and it is curious that it happens only on XT and sometimes on Vista, but never on W2K. I do not have Win7 to test on.

I will try some of your ideas, only because I have nothing to lose. If they magically fix my problem, then I will return here to eat crow.

Quote:

---

Originally Posted by cosmicvoid

I have never heard if this in 15 years of GDI programming. I wonder why not.

---

That's strange. Check out MSDN:
An application should always replace a new object with the original, default object after it has finished drawing with the new object.

Some versions of Windows are more forgiving than others, and not all GDI objects cause the same damage.
You just might have a longest streak of luck.

The very first hit: SelectObject. And you have your warning alright:

Quote:

---

Remarks

This function returns the previously selected object of the specified type. An application should always replace a new object with the original, default object after it has finished drawing with the new object.

---

Quote:

---

Originally Posted by VladimirF

Some versions of Windows are more forgiving than others..

---

..or rather current complexity just exceeded tolerance threshold :)

I had the same problems, with a different program where I always carefully replace and deselect objects that I use, consciously following the basic guidance of Charles Petzold. So the problem is not caused by any resources that are not rightly freed or released.

The problem I noticed occurs when there is a scrollbar, and I see that cosmicvoid must also have a srcollbar, since he uses si.nPos. I believe the problem is a bug in some versions of Windows, because the window is supposed to be unchanged, when it actually is, and this would be the reason the extra unvalidateRect() is working, because it is placing a message in the queue forcing a repaint. But it seems the problem does not exist anymore with Windows 7.

Well, I see that I am proven wrong about the GDIOBJECT select/deselect, and I admit my mistake :(. I guess that's what happens when you keep re-using chunks of programs that were developed on Win98 :eek:.

So, after adding a lot of lines of code to "pair up" the object select and restore, I am disappointed to report that the program behavior is exactly the same: it is trouble free on Win2K, flickers slightly on Vista, and flickers/ghost trails badly on XP.

@olivthill2: Yes, there is a scroll bar sometimes, depending on the user's screen size vs the size of the image. It makes no difference whether the scroll bar is in use or not.

So those changes are not the magic bullet :(, and I am still hoping for ideas to try.

First of all you are to find out when the problem occurs: just dump your buffered image to file and see if it gets spoiled before blitting. If it doesn't, try to play with display settings (it might be display driver problem), etc.

If you post an SSCCE you may get better help and/or an actual solution or fix (time won't be wasted on guessing).

What is sdc and where is it configured? Have you tried blitting the entire bitmap to the entire client area instead of just the clip box portion? You may be calculating the dimensions and/or offset incorrectly.

Like Martin suggested (above), a sample might help. Or at least some complete real code fragment.

Quote:

---

Originally Posted by cosmicvoid

Code:

---

        case WM_PAINT:
                if (GetActiveWindow() != hWnd) InvalidateRect(hWnd, &re, 0);
                dc = BeginPaint(hWsbox, &ps);
                SelectObject(dc, hBm);
                BitBlt(dc, ps.rcPaint.left,
                        ps.rcPaint.top,
                        ps.rcPaint.right - ps.rcPaint.left,
                        ps.rcPaint.bottom - ps.rcPaint.top,
                        sdc, ps.rcPaint.left,
                        ps.rcPaint.top + (scroll ? si.nPos * (SEL_RY + fhgt) : 0),
                        SRCCOPY);
                EndPaint(hWsbox, &ps);
                break;

---

---

What is hWsbox here? Is it the same as hWnd?
What is hBm? And why do you select it into dc before BitBlt'ing into it?

Quote:

---

Originally Posted by Martin O

If you post an SSCCE you may get better help and/or an actual solution or fix (time won't be wasted on guessing).

---

Yes, good advice. Here is a trimmed source file that demonstrates the problem.

As for the idea that the bitmap content is perhaps being corrupted, I don't suspect this, since when the app becomes the active window again, the repaint is perfect. The repaint is corrupt only when another window moves across mine. The WM_ERASEBKGND is commented out because it has a bad side effect: the button area at the bottom of the dialog doesn't repaint, but it seems to cure the bitmap image repaint corruption.

I didn't include an exe file because I think no one would trust running it.

Quote:

---

Originally Posted by cosmicvoid

Yes, good advice. Here is a trimmed source file that demonstrates the problem.

---

OK, I can see the defect that you described.
One thing that jumps out: you can't call BeginPaint() for whatever window you want; you can only call it for window that received that WM_PAINT message.
I am pretty sure that this is your problem.

Here is how this should be done.
You need to subclass your static control and implement WM_PAINT handler there, just like you did in your dialog proc.
To eliminate flicker you need to add WS_CLIPCHILDREN flag to your dialog.
Oh, and don’t mess with WM_ACTIVATE message.
Attached is your corrected paint_sscce.cpp file.

Thank you hugely for an excellent solution. I would not have thought of subclassing that window to paint itself. I owe you, big time :thumb:.

Quote:

---

Originally Posted by VladimirF

Oh, and don’t mess with WM_ACTIVATE message.

---

Yeah, that was strictly a band-aid also, since the app wasn't repainting itself when it became topmost.

Quote:

---

Originally Posted by cosmicvoid

Thank you hugely for an excellent solution.

---

You are welcome.:wave:

Quote:

---

Originally Posted by cosmicvoid

I have never heard if this in 15 years of GDI programming. I wonder why not.

---

I wonder too. Your 15 years of experience makes me feel humble, I only have 13. Of course, of Windows GDI experience. Otherwise my first contact with a computer to program it was 31 years ago.

I almost don't dare to suggest you to read the following quote from the MSDN:

"An application should always replace a new object with the original, default object after it has finished drawing with the new object."

Link: http://msdn.microsoft.com/en-us/libr...57(VS.85).aspx

As about "de-selecting" graphic objects, I have to admit it's not standard terminology, but if you don't understand what I mean, I'm afraid I can't help you.

Quote:

---

Originally Posted by srelu

I almost don't dare to suggest you to read the following quote from the MSDN:

"An application should always replace a new object with the original, default object after it has finished drawing with the new object."

As about "de-selecting" graphic objects, I have to admit it's not standard terminology, but if you don't understand what I mean, I'm afraid I can't help you.

---

I understand exactly what you mean, now. I don't mind being shown the errors of my ways, as I still have much to learn.

Back in the mid '90's, when I started doing Windoze programming, I was pretty isolated. There was no internet access at my job, and I didn't have a subscription to MSDN. The only source of info, for me, was the programming tutorial books that I bought, and the built in help in Visual Studio. I took a lot of code from the book examples (which tend to be simplified), and was ignorant of many details of the methods. I usually only went digging for details when something didn't work. So, if Win95 and Win98 were forgiving of these kinds of errors, then how was I to know better??

To All,

Is this the same problem as with Charles Petzold's Programming Windows, 5th Edition, Chapter 14, program BITBLT.C, as given in the attachment? It works fine on XP but not on Vista. Does this program have to be sub-classed also? Ratch

What's it supposed to do and what is it doing wrong in Vista? Seems to work fine in Win7.

hoxsiew,

It is supposed to copy the IDI_INFORMATION icon in the upper left corner of the window and repetitively paste it in the client window. It works OK on XP, but not on my Vista machine. It either "captures" the wrong rectangle or outputs garbage. I am surprised it works on Windows 7. Anyone try it out on Vista? Thanks, Ratch