Winboard 4.3.15m feature request: remember window locations

[Dave Gomboc]

It'd be great if the program remembered where the windows were when the application was last closed, and put them back at the same regions on the screens (after checking that the screen resolutions still permit the remembered co-ordinates).

[hgm]

WinBoard already does that, isn't it? Ever since Winboard_x. Only the -stickyWindows option is broken on the newer Windows systems (XP and Vista).

XBoard of course does not remember anything; there is no xboard.ini file.

[Charles B.]

H.G.Muller

In this Winboard forum post (at the bottom of the post) you wrote about some kind of license needing to be displayed (I forget the variant needing the license) and that is why your Winboard did not remember its settings from when it was last opened. (?)

http://www.open-aurec.com/wbforum/viewt ... 66#p186666

[Dave Gomboc]

WinBoard already does that, isn't it? Ever since Winboard_x. Only the -stickyWindows option is broken on the newer Windows systems (XP and Vista).

XBoard of course does not remember anything; there is no xboard.ini file.

Thanks, I wasn't aware that a command-line switch exists to enable the behaviour. I'll give it a go. (This option should probably be enabled by default.)

[Kempelen]

WinBoard already does that, isn't it? Ever since Winboard_x. Only the -stickyWindows option is broken on the newer Windows systems (XP and Vista).

XBoard of course does not remember anything; there is no xboard.ini file.

Hi H.G., it would be nice to allow winboard remember the position for a second monitor. I use two and is very confortable because a tournament can be running while using the computer in the other.
FS

[hgm]

Thanks, I wasn't aware that a command-line switch exists to enable the behaviour. I'll give it a go. (This option should probably be enabled by default.)

This is not the switch that causes WinBoard to remember its window locations. It should always do that (unless you have -saveSettingsOnExit false) The -stickyWindows option is supposed to glue windows together, so that when you move the main window, all windows touching it move along with it. This works on my Win2k, but not on XP or Vista. No idea what was changed in Windows to break it.

As to the matter of second screens: I really have no idea how this works, and cannot test it myself. When I am back from Pamplona I can have a look how the current mechanism of obtaining the window positions and sizes, (for storing in the .ini file) and restoring them is done with Windows API calls. Perhaps someone having two monitors could then explain me how that would have to be changed for multiple monitors.

As to the license message: this was not so much that the old position was not remembered, but that I had added code not to accept initial positions too close to the upper-left corner of the screen. But I removed that code after the discussion referred to above. So that should no longer be a problem.

[Kempelen]

As to the matter of second screens: I really have no idea how this works, and cannot test it myself. When I am back from Pamplona I can have a look how the current mechanism of obtaining the window positions and sizes, (for storing in the .ini file) and restoring them is done with Windows API calls. Perhaps someone having two monitors could then explain me how that would have to be changed for multiple monitors.

I attach you code of how second monitors works with Windows APIs.

Code: Select all

Screen monitor1 = System.Windows.Forms.Screen.AllScreens[0];
Screen monitor2 = System.Windows.Forms.Screen.AllScreens[1];

Form f = new Form();
f.Location = monitor2.Location;
f.Size = monitor2.Size;
f.StartPosition = FormStartPosition.Manual;
f.WindowState = FormWindowState.Maximized;
f.Show();

As you can see, it is quiet simple. I have also found code like this:

Code: Select all

Public Class Form1

    Public Declare Auto Function MoveWindow Lib "user32.dll" (ByVal hWnd As IntPtr, ByVal X As Int32, ByVal Y As Int32, ByVal nWidth As Int32, ByVal nHeight As Int32, ByVal bRepaint As Boolean) As Boolean
    Public Declare Auto Function FindWindow Lib "user32.dll" (ByVal zero As IntPtr, ByVal lpWindowName As String) As IntPtr

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

        Dim NewPos As Integer
        Dim h As IntPtr = FindWindow(0, "Untitled - Notepad")

        NewPos = Screen.PrimaryScreen.Bounds.Left + 1
        Call MoveWindow(h, NewPos, 0, 200, 200, False)

    End Sub
End Class

It is VB, but it would be similar for other languages, althought this last sample is less clean.

I am developing a new tournament manager specially for your winboard and have toying with this last one code to move the window to second monitor. I get windows handle and then try to move it, but using this second way to deal with position I have not been able to move it. I suspect the only way is to move it from own winboard code as the first way show.

Second monitor is one of the major features I have found for programmers. It is very confortable and clean. I.e. you can have error-window and file-explorer-window in monitor 2 and the editor in 1. Also you can have manual pages in minitor 2 which save you a lot of alt+tab. You can also have samething running in background/monitor 2 while using the first one to navigate are so on. Believe me, it is one of the most great tools a programmer must have.

Regards.