James Harvey wrote:

> [ I've just re-subscribed to this list after a while away. 
>   I downloaded and built vim 7 (from subversion) and found this bug
>   myself ]
> 
> > > On a windows xp multimonitor system, if I do the following:
> > > 
> > > 1. Ensure 'guioptions' contains 'L'.
> > > 2. Postion the gvim window such that it is at least partly drawn on
> > > the secondary monitor.
> > > 3. Create a vertical split or close a vertical split.
> > > 
> > > The gvim window will move horizontally such that the gvim window's
> > > right edge is on the right most edge of my primary monitor.  (My
> > > primary monitor is on the left, my secondary is on the right.)  Also,
> > > (and this is a very minor nit) the whole gvim window will widen by an
> > > amount equal to the thickness of the vertical scrollbar.
> > > 
> > > In addition, if the windows taskbar is at the top of the primary
> > > monitor, the gvim window will also move downward by an amount equal
> > > to
> > > the thickness of the taskbar.
> >
> > Well, this problem is older, since Vim 6.4 behaved like that, too. If a
> > vertical split is created and guioptions contain L, a scrollbar is
> > added which makes the windows wider by the amount of the scrollbar. I
> > have removed the L from the guioptions and don't miss it.
> > 
> It did indeed, and I patched it then, too, but I guess I never
> submitted the patch. 
> 
> The problem is that the code in gui_mch_set_shellsize that works out the
> new position of the window double-compensates for the origin of
> non-primary monitors.  
> 
> An example: if I move a window to my secondary monitor (happens to be
> to the right), and then run :vsp (which, in my setup, gives a second
> scrollbar, thus making the window bigger):
> 
> * get_work_area returns a window from 1024 --> 2048 across, and 0 -->
>    1202 down (my monitors run in portrait mode). 
> * GetWindowPlacement then returns *its* work area from 1172 --> 1857
>    across, and from 165 --> 901 down. This includes the X offset implicit
>    in the result of get_work_area.
> 
> However, the code then a) makes the wrong check for going off the screen,
> and b) subtracts the work area x offset again, causing the window to be
> hoiked back to the primary monitor. 
> 
> My patch below fixes this for me. I can't remember the patch I wrote for
> vim6, but this was from scratch for vim7 -- tested on XP, but certainly
> I had problems with vim6 on win2k as well. In any case, this patch will not
> affect users with a single monitor, because the values removed from
> calculations are all zero.

Your code fails when using one monitor and the taskbar is at the left or
the top of the screen.  In this situation the window position is
relative to the workarea.

Example: Suppose the taskbar is at the bottom of the screen and
auto-hidden, and the Vim window is at 200 from the left and zero from
the top.  Then the numbers are:
        workarea left:0 right:1024 top:0 bot:768
        Window: left:200 top:0

If I now move the taskbar to the left of the screen and disable
auto-hide, without moving the Vim window, then the numbers are:
        workarea left:94 right:1024 top:0 bot:768
        Window: left:106 top:0

You can see the size of the taskbar is subtracted from the window
position.  Thus to compute the position of the right edge of the Vim
window the workarea left offset must be added.

It is very strange that GetWindowPlacement() returns a value of 1172 for
the window position.  This is not consistent with using one monitor.

We could check if the workarea left offset is more than, say, 300 to
detect placement on the second monitor.  And then use your code.

Please try out the patch below.  Especially check with different
placement of the taskbar.  I would suspect that when the taskbar is in
the second monitor on the left something might be wrong.  But that's
quite an unusual position for the taskbar.

I didn't do the vertical stuff.  Does anyone use two screens above
each other?

--- gui_w32.c   30 Apr 2006 18:42:42 -0000      1.41
+++ gui_w32.c   6 May 2006 19:50:24 -0000
@@ -1599,6 +1599,7 @@
     int                win_width, win_height;
     int                win_xpos, win_ypos;
     WINDOWPLACEMENT wndpl;
+    int                workarea_left;
 
     /* Try to keep window completely on screen. */
     /* Get position of the screen work area.  This is the part that is not
@@ -1632,11 +1633,21 @@
 #endif
                        ;
 
+    /* There is an inconsistency when using two monitors and Vim is on the
+     * second (right) one: win_xpos will be the offset from the workarea of
+     * the left monitor.  While with one monitor it's the offset from the
+     * workarea (including a possible taskbar on the left).  Detect the second
+     * monitor by checking for the left offset to be quite big. */
+    if (workarea_rect.left > 300)
+       workarea_left = 0;
+    else
+       workarea_left = workarea_rect.left;
+
     /* If the window is going off the screen, move it on to the screen.
      * win_xpos and win_ypos are relative to the workarea. */
     if ((direction & RESIZE_HOR)
-          && workarea_rect.left + win_xpos + win_width > workarea_rect.right)
-       win_xpos = workarea_rect.right - win_width - workarea_rect.left;
+           && workarea_left + win_xpos + win_width > workarea_rect.right)
+       win_xpos = workarea_rect.right - win_width - workarea_left;
 
     if ((direction & RESIZE_HOR) && win_xpos < 0)
        win_xpos = 0;

-- 
To define recursion, we must first define recursion.

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Reply via email to