Gotcha now. But commonly, the right and bottom-aligned elements are not the
window's non-client area (scroll bars). They might be a status bar or
child's scroll bars, for example. So that wouldn't help there. If it's just
Exactly.
It should do what it is doing (move + resize)... but Windows should have a
better implementation, so it doesn't look so ugly.
As I said earlier, I was able to fix this in my application, so there is
no reason the standard Windows implementation can't be better.
How did I fix it? Quite simple actually (although I messed around with it
for 2 days)...
GetCurrentWindowRect(&rectOrig);
DoCalculationsToFigureOut new x,y,cx,cy
SetWindowPos(hWnd, NULL, x, y, cx, cy, SWP_NOZORDER | SWP_NOACTIVE |
SWP_NOREDRAW); // <=== key flag to make this work
At this point, I have the original window rectangle, and have moved and
resized the window. Because of the SWP_NOREDRAW flag, Windows did not do
the redrawing the same way, so if your resizing makes the window *bigger*,
you have perfection... the scroll bars did not jump around like crazy, the
window below did not flash through, etc.
However, if you made the window smaller, the desktop will now be a mess...
so a simple call to:
CWnd::GetDesktopWindow()->RedrawWindow(&rectOrig, NULL, RDW_ALLCHILDREN |
RDW_NOERASE | RDW_INVALIDATE);
will clean up the desktop:
1) Yes, all 8 resizes now work perfectly
2) No, there does not seem to be any system performance impact (unless you
pass NULL to RedrawWindow())
3) No, there is no mess on the desktop
So it is quite possible to do this with existing PCs and the existing OS,
its just that Windows has a poor implementation of the default way of
doing it and *that* is the bug.
"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:eU%23j$aGgIHA.1132@TK2MSFTNGP06.phx.gbl...
Not quite. For this window, it makes BitBlt of the whole window
(including its scrollbar) on its behalf to move its image, then resizes
its right edge back. This is why the scrollbar jumps. It should be
smarter and just move non-client area.
"Paul Baker [MVP, Windows - SDK]" <paulrichardbaker@community.nospam>
wrote in message news:%23wK0Z%23FgIHA.1212@TK2MSFTNGP05.phx.gbl...
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.