James Harvey wrote:
> On Sat, May 06, 2006 at 10:23:50PM +0100, James Harvey wrote:
> > On Sat, May 06, 2006 at 10:13:36PM +0200, Bram Moolenaar wrote:
> > > James Harvey wrote:
> > > > [snip description of multi-monitor resize window bug]
> > >
> > > 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.
> >
> > Oh, drat, it's even more confusing than I thought. :( Apologies.
> >
> > > 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.
> >
> > Gaaah. I have a feeling that GetWindowPlacement() is using a value for
> > the offset from the entire visible area across all monitors (but
> > relative to any taskbar). Which doesn't play nice with our get_work_area
> > function that carefully fetches the work area of only the current
> > monitor.
>
> A search of the MSDN library came up with this:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/monitor_9t0w.asp
>
> which is, basically, that they recommend using
> GetWindowRect/SetWindowPos alongside GetMonitorInfo, instead of
> Get/SetWindowPlacement.
>
> This _almost_ works; I attach a patch that uses this method. I've moved
> my taskbar around my monitors, and it seems to be correctly taking this
> into account, and if my secondary monitor is to the right of my primary
> (so its coordinates are large positive) it DTRT.
>
> However, if my secondary monitor is left of primary (and thus has
> negative coordinates) it still yanks itself onto the primary screen
> occasionally; on a vertical-split, and a set-columns, but not if you
> change a vertical-split window to remove the split.
>
> Adding debug to the code tells me that the SetWindowPos is doing the
> right thing, because a GetWindowRect immediately afterwards is returning
> the -ve coordinates passed in. So my hunch is that there's something
> else (either in vim, or else a bug in SetWindowPos) that's moving it to
> have X coordinate 0.
>
> I don't know vim's UI code all that well, so I'll keep digging, but does
> anyone have any other ideas of any code that might assume all window
> coordinates are +ve?
>
> But, this patch certainly fixes the problem for me in the usual case,
> and also seems to work with toolbars.
This is too complicated to change now. At least it should be tested
with various compilers and libraries.
Please keep working on it, we can make a patch for Vim 7 later, when it
has been tested properly.
I'll include the simple change that I sent previously. It doesn't
change anything for when there is one monitor and should help a bit for
when there are two.
--
Micro$oft: where do you want to go today?
Linux: where do you want to go tomorrow?
FreeBSD: are you guys coming, or what?
/// 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 ///
