Repaint failure

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