Window resizing works funny
Brought to you by:
bozho
When resizing by dragging the top or the left border,
the Console window does not always end up where intended.
Let's say I for example make the window height smaller
by dragging on the top border 100 px down. What
happends when I let go is actually that the top border
is moved only 50 px down and the bottom 50 px up.
Almost the same happends when I drag the left border.
Also the outcome is different if I either make the
window smaller or larger.
(using Console 2.00 Beta 126)
Logged In: YES
user_id=16767
After you finish resizing Console window, it will adjust its
size in order to fit it to the nearest row/column count.
This is done at the bottom and right window edges. Could
that be what you're seeing?
Is the number of pixels that bottom/right edge moves
'proportional' to the resize or not?
Sample console config file showing a small console in the lower right corner of the screen
Logged In: YES
user_id=1251991
As far as I can see you in some way correct about the "snap
to nearest row/col" when it comes to dragging the left
border to the left (horizontal resizing from the left) - but
it depends on the setup of the console.xml.
Either way I am (so far) still able to see the problem all
the time when resizing vertically by dragging the top border
down (making the window smaller). In that case the bottom
border is not only moved half a row up or down, but many
rows (depending on how much I resize).
In any case I think that it is not good behavior to move the
opposite border in order to "snap" to the nearest row/col.
The Console app should move only the border that the user is
dragging. This becomes especially crucial when working with
a Console that is snapped to the corner/ege of the screen.
Try for example to load the attached logconsole.xml file (it
should appear in the lower/right corner of the screen) and
drag the left border towards the right, release it and see
what happens with the right border - now it is no longer
snapping to the right of the screen.
Logged In: YES
user_id=16767
Originator: NO
Have you tried this with latest builds?
Logged In: YES
user_id=1251991
Originator: YES
I'm sorry to say, that I've switched to Mac and OS X, so I'm not running Console anymore
Logged In: YES
user_id=1664805
Originator: NO
Marko,
I think I found this one. The problem is in MainFrame::OnWindowPosChanging: you can't use GetWindowRect when you're trying to snap. It's invalid at this point - it's the "original" one. You need to use cx, cy instead of rectWindow.Width(), rectWindow.Height().
Also, I would suggest to use:
Helpers::GetDesktopRect(CRect(pWinPos->x, pWinPos->y, pWinPos->x + pWinPos->cx, pWinPos->y + pWinPos->cy), rectDesktop);
instead of your current GetDesktopRect(pointCursor...) because:
- if somehow OnWindowPosChanging is delivered much later [and mouse position has nothing to do with the window position any more], the window will jump inexplicably;
- it seems slightly more logical to go with the amount of window on the alternate monitor than with mouse position. Consider this: I undocked my laptop, but it "did not realize" that it lost the second monitor (for example, it will happily move my mouse over there). I do agree that the mouse cursor could be a better choice, but if you insist I would suggest to find something like "MousePosOfThisEvent" (essentially, position of the mouse when the event happened, not when it's delivered).
Hope it helps a bit!
--
Kirill.