[API Proposal] System.Windows.WindowStartupMonitor

In times of multi monitor setup I would like to propose a new API that allows us to set the startup monitor of the window. I am open for naming changes. The reason is that many developers would prefer to use/keep the WindowStartupLocation.CenterScreen but only change the monitor from “the monitor on which the mouse is currently located” to a fixed monitor.

The way to do this ourselves is tedious. Enumerating all screens, calculating the center, use WinAPIs to move the window. WindowStartupMonitor could be an integer which stands for the index of the monitor. By default it could be -1 which means “the monitor on which the mouse is currently located”.

Ideas? Suggestions?

[miloush]

if CenterScreen is used WPF automatically chooses the monitor where the cursor is

Exactly what I was talking about in terms of messing with the OS window management 😃 and this is just more of it.

Since that is already the case though I am changing my position here and would entertain the idea of adding some API to make it simpler. The issue of monitory identity, however, remains. WPF does not use the WinForm’s Screen class. The numbering via the “Identify Monitors” features in Settings is an implementation detail and also uses values like “1|2”. I don’t see any guarantees for HMONITOR to be stable or for EnumDisplayMonitors to enumerate monitors in the same order. I am guessing that might be one of the reasons for the Screen class to cache the results and throw them away when the monitors change.

I was surprised that all it needs is just a few lines to launch it on a specific monitor and not the monitor where the cursor is.

If by “monitor” you mean HMONITOR, then yes, you can easily give the existing code a different HMONITOR. The difficult part is finding the HMONITOR that you want.

If you want the user to specify the monitor (or have the window open at the same monitor it was on last time), it looks like using either monitor name or the MonitorFromPoint could do the trick. Name could be useful for scenarios like “I want the monitor with HDR, regardless on which side it is”, but it would require to basically duplicate all the Screen class functionality for developers to find out the current monitor’s name. The MonitorFromPoint on the other hand I would think is more promising. For example, Window could have an overridable method that would return a point on the monitor it should appear on, defaulting to the mouse cursor point. Would that address your scenario?

The way to do this ourselves is tedious.

The problem is that unless you want a primary monitor or the monitor the window was last on, it takes non-trivial code to figure out which screen you want. For example, imagine an application like PowerPoint, where you want to show the presentation on a different monitor than the current window is. You still need to find out which monitor the current window is on and which is the other monitor available. If you want to display a window on the left monitor, you have to enumerate the monitor rectangles and figure out which one is on the left. Even if you assumed that EnumDisplayMonitors returns always the same order, I don’t really see a scenario where you would supply a random index without doing some non-trivial work of finding out what the index should be.

[Symbai]

Again isn’t that what Windows does by default

No. And for WPF applications as I said in the very first post, if CenterScreen is used WPF automatically chooses the monitor where the cursor is. So even IF Windows does that by default (which it does NOT), it wouldn’t work for WPF. My API proposal allows both, launching + centered on a specific screen.