Window Positions on Multi-monitor systems

[CoastalMaineBird]

LV2013, Win7

I need to store window positions in a PREFS file (*.ini), so that if the user shuts down today, tomorrow's start-up leaves them in the same place.

I have two monitors, my customer has four on his dev. machine, the production machines for this system have three.

I had a previous project that used the FP.MONITOR property to put a window on the correct monitor, but that was always centered.

Right now, I am using FP.PanelBounds, and storing the four coordinates like this:

[Window Settings]
Main Window Left = -1760    
Main Window Top = 151    
Main Window Right = -960    
Main Window Bottom = 751    

The window is 800 x 600, obviously.

So, apparently, these coordinates are the desktop coordinates, treating the deaktop as one big space.

If I edit the INI file to say the LEFT, RIGHT are +160 and +960, and tell the RESTORE code to put it on monitor #1, then the window comes up in (roughly) that same position.  But if the SAVE code reads the FP.MONITOR and saves that, then restores it, it's going to keep marching left and left and left.

So, it's not right to record the FP.MONITOR number, because the BOUNDS numbers are all relative to monitor #0.

Fine.

If I edit the INI file to deliberately put the window outside the desktop, it will happily oblige.  The window comes up and cannot be seen.  I was thinking maybe the window manager would prevent that, but not so.  The window is there and responds to keyboard stuff, but you cannot see it.

That's no good.  If the user unplugs a monitor that previously held one of my windows, then he cannot get it back (short of editing the INIT file manually).

So, it looks like I have to detect the ALL MONITORS desktop and do my own arithmetic to decide if the stored position is legal or not, and use some default if it's not.

Does anyone have any better ideas?

[zou]

>  If the user unplugs a monitor that previously held one of my windows, then he cannot get it back (short of editing the INIT file manually).

You can move the window back in the following way:

1. alt+tab: to make the window active

2. alt+spacebar: to make the system menu popup at the top-lelt corner of the window (you can't see the menu, but it doesn't matter)

3. M key: select move

4. left key: make the window stick to the cursor.

5. move the cursor to move the window back.

You can try this on a visible window.

[CoastalMaineBird]

Thanks for the idea, George.  That works, but it's less than ideal.

1... The alt+tab doesn't work in the DevSys: if LabVIEW DevSys is running, then selecting the rogue window via Alt+tab actually selects the PROJECT window.  Alt+space then brings up the menu attached to that, which is not helpful.  You have to alt-tab to the desktop and select that, which hides everything. Then alt-tab to the rogue window and try the menu.

2... You can use the Win-Tab to select it directly.  I think all my folks are Win7+, so that would be better.

3... The alt-space brings up the menu where it's guaranteed visible, not attached to the rogue window.  That is a plus.

4... You have to know which way to steer the rogue window toward the desktop.  There is no feedback.

5... I don't like relying on the user remembering this sequence.  I'd rather be automatic about it, but I'm not sure I can.

I do appreciate the ideas, though.

[zou]

> 5... I don't like relying on the user remembering this sequence.  I'd rather be automatic about it, but I'm not sure I can.

Create a VI for users to manage this:

Enumerate all VIs.

List VI names, their bounds and visiblity in a MCListbox.

One button to bring to selected VI to the center of the primary monitor.

If a VI is set to run when open, then you can automate this.

[Sam_Sharp]

Hi,

For saving the window position, I just store/load the FP Window: Panel Bounds on startup/shutdown and that works for me - even with multiple monitors.

For making sure that the window appears on the screen even if the resolution/monitor layout changes I have the following:

It was actually for a different purpose - I have a little custom tipstrip VI that appears when you hover over a control - I wanted it to always appear on screen even if the text is long which would cause it to overflow out of the monitor bounds.

Note that it only checks it's in bounds to the right - but you should be able to adapt to your needs - you should be able to modify so that regardless of monitor configuration, all of the windows will load with the front panel fully within the monitor bounds.

Oh, and there's nothing wrong with having a 'reset window positions' menu option!

Also - shouldn't the preferences be local to that machine? You would configure/save the preferences for each computer, surely? If that's the case...then it's much less likely the user is going to add/remove monitors.

[CoastalMaineBird]

Thanks for your thoughts, Sam.

For saving the window position, I just store/load the FP Window: Panel Bounds on startup/shutdown and that works for me - even with multiple monitors.

Yes, I've decided that the FP.Monitor property is not useful for me.

For making sure that the window appears on the screen even if the resolution/monitor layout changes I have the following:

Yeah, that's the arithmetic I was referring to.  But you're aware that your logic has a hole in it, right?

What you compute is the farthest right margin of ANY monitor ("R" in the pic)

If your window wants to come up at "x", that code will let it, even though it's off screen.

Oh, and there's nothing wrong with having a 'reset window positions' menu option!

True.  If we have menus (I'm not sure yet), then that would be easy.

Also - shouldn't the preferences be local to that machine? You would configure/save the preferences for each computer, surely?

Of course.  And don't call me Shirley  😉

If that's the case...then it's much less likely the user is going to add/remove monitors.

I don't see why.  I suspect they will get borrowed / swapped / traded around a bunch.

Anyway thanks for your thoughts.

[Sam_Sharp]

- You could always save the FP.Monitor property so that if it has changed since the last run, you reset the window positions to default values?

- Yes, it definitely has holes in it! I was only interested in the right side of the monitors as in my case we only ever have two monitors side by side and it's just to make sure the right margin of the tipstrip VI (which changes in size depending on the amount of text) is in bounds. A more robust solution would check all four bounds (and you can see I had started to add code for the bottom side)!

- Sure, the monitor configurations will/can change - but generally it's not like it's going to happen every hour/day?! If it does change, at least you'd kind of suspect that your preferences might not be quite right and/or the windows might be in a different position.

[JÞB]

If that's the case...then it's much less likely the user is going to add/remove monitors.

I don't see why.  I suspect they will get borrowed / swapped / traded around a bunch.

---

That's a scary production enviornment!  you need to be clear that just moving equipment around like that, changeing the system resources,  with no plan or tracking is undesireable.  Heaven help you if you are subject to regulatory audits. Still much better to treat your systems as systems and have some configuration change process to update that equipment was added/removed. (Which signals them to update system settings with that nice utility that sets window positions on config change)