#106 Window resizing works funny


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)


  • Marko Bozikovic

    Marko Bozikovic - 2006-09-21

    Logged In: YES

    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?

  • wa7son

    wa7son - 2006-09-21

    Sample console config file showing a small console in the lower right corner of the screen

  • wa7son

    wa7son - 2006-09-21

    Logged In: YES

    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.

  • Marko Bozikovic

    Marko Bozikovic - 2007-04-22
    • priority: 5 --> 3
  • Marko Bozikovic

    Marko Bozikovic - 2007-04-22

    Logged In: YES
    Originator: NO

    Have you tried this with latest builds?

  • wa7son

    wa7son - 2007-04-22

    Logged In: YES
    Originator: YES

    I'm sorry to say, that I've switched to Mac and OS X, so I'm not running Console anymore

  • Kirill

    Kirill - 2008-02-05

    Logged In: YES
    Originator: NO


    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!



Log in to post a comment.