Not quite. For this window, it makes BitBlt of the whole window (including
back. This is why the scrollbar jumps. It should be smarter and just move
Well it *is* a size and a move. That's fine. The question is how it is
implemented.
In order for the window to paint itself, the application has to be
responding. So, it first shifts the graphic of the window and then it
erases/repaints. If the program does not respond to erase/paint, the
window is still close to what it's supposed to be and not a big old mess.
I think I see your point now. But what would you rather it do that is less
flickery? The frame of the window has to move immediately in order to give
the user reasonable feedback. What would you have the window look like
within this frame in the mean time? It's already the closest it has (the
old image).
Paul
"Somebody" <somebody@cox.net> wrote in message
news:J72Aj.12523$0M3.9987@newsfe17.lga...
"Paul Baker [MVP, Windows - SDK]" <paulrichardbaker@community.nospam>
wrote in message news:uTjrm46fIHA.6136@TK2MSFTNGP03.phx.gbl...
Which two phases are you talking about? WM_ERASEBKGND and WM_PAINT?
That's just a convenience. You can do all the handling in WM_PAINT if
you want and design it to minimize flickering. Is the "bug" just with an
edit control and its default message processing? Notepad does flicker a
little excessively on my computer and when compared to other
applications.
I would like you to decide where you believe this "bug" lies so we can
limit our discussion to that.
Paul
No, not WM_ERASEBKGND / WM_PAINT...
There are 8 different resize points on a window and they fall in 2
categories:
size only: right, bottom and bottom right
size + move: left, top, top left, top bottom and top right
"size only" are resizes where its only necessary to increase the size of
the window... the cx, cy so to speak. The x & y stay the same.
"size + move" are resizes where ALL are changing... x,y,cx and cy... that
is a move occurs AND a size occurs...
What I meant by "Windows is doing this in 2 passes" is that it first does
a move and repaints, and then it does a size and repaints again. 2 passes
to do a single operation. Thats why you see the scroll bars jump around
and the window underneath flicker through when you do a "size + move"
resize.
THAT is the Windows bug: that Microsoft is doing it in 2 steps instead of
one. Check the WM_WINDOWPOSCHANGING messages you get: you'll get one with
WM_NOSIZE and then a second one with WM_NOMOVE.