(following up to myself, first sign of madness)
On Sun, May 07, 2006 at 11:58:12AM +0100, James Harvey wrote:
> 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?
Aha, found it. The bug is in the following code, in gui.c:
gui_mch_set_shellsize(width, height, min_width, min_height,
base_width, base_height, direction);
if (fit_to_display)
{
int x, y;
/* Some window managers put the Vim window left of/above the screen. */
gui_mch_update();
if (gui_mch_get_winpos(&x, &y) == OK && (x < 0 || y < 0))
gui_mch_set_winpos(x < 0 ? 0 : x, y < 0 ? 0 : y);
}
On windows, with multiple monitors, gui_mch_get_winpos will definitely
return negative numbers for windows that are to the left or above the
primary monitor, and the gui_mch_set_winpos call here is the one that's
then moving the window a second time so as to not have negative
coordinates.
If it's essential for other systems to not have negative coordinates
here, it might be worth the windows gui_mch_*_winpos functions
offsetting from the top-right of the entire virtual screen; this is
SM_XVIRTUALSCREEN and SM_VIRTUALSCREEN (from GetSystemMetrics) so as to
make all coordinates positive.
-James
