By definition, the primary monitor is the monitor that has (0,0) as its upper left corner. Why can’t the primary monitor be positioned somewhere else?
Well, sure you could do that, but then you’d have to invent a new name for the monitor whose upper left corner is at (0,0), and then you’re back where you started.
In other words, it’s just a name. You could ask, “Why can’t starboard be on the left-hand side of the boat?” Well, sure you could do that, but then you’d have to come up with a new name for the right-hand side of the boat, and then things are pretty much the same as they were, just with different names.
Perhaps a more descriptive (but clumsier) name for the primary monitor would be the backward-compatibility monitor (for applications which do not support multiple monitors), because that’s what the primary monitor is. If an application is not multiple-monitor aware, then any time it asks for properties of “the” monitor, it gets information about the backward-compatibility monitor. A call to GetSystemMetrics(SM_CXSCREEN)
gives the width of the backward-compatibility monitor, GetSystemMetrics(SM_CYMAXIMIZED)
gives the height of a window maximized on the backward-compatibility monitor, and positioning a window at (0,0) puts it at the upper left corner of the backward-compatibility monitor.
The window manager still respects window coordinates passed to functions like CreateWindow
or SetWindowPos
. If you pass coordinates that are on a secondary monitor—oops—a monitor different from the backward-compatibility monitor, then the window manager will happily put the window there. These coordinates might be the result of a program that is multiple-monitor aware, or possibly merely from a program which is multiple-monitor agnostic.
Multiple-monitor agnosticism is a term I just made up which refers to programs which might not explicitly support multiple monitors, but at least were open to the possibility of multiple monitors by not making assumptions about the number of monitors but instead using functions like RectVisible
to determine what the visible portions of the screen are. These techniques were hot topics many years ago when you wanted to write a program that ran both on single-monitor-only versions of Windows as well as multiple-monitor versions of windows; nowadays there are rather old-fashioned, like coming up with mnemonics for all your friends’ telephone numbers so you didn’t have to keep looking them up. (Today, you just go ahead and call the multiple monitor functions and use the address book function in your mobile phone to remember your friends’ phone numbers.)
It is not the case that the primary monitor is the applications show up here first monitor. As noted earlier, applications show up on whatever monitor they ask for, whether they asked for it explicitly (hunting around for a monitor and using it) or implicitly (restoring to the same coordinates they were on when they were last run).
Of course, programs which pass CW_USEDEFAULT
to the CreateWindow
function explicitly abdicated the choice of the window position and therefore the monitor. In that case, the window manager tries to guess an appropriate monitor. If the new window has a parent or owner, then it is placed on the same monitor as that parent or owner; otherwise, the window manager just puts the window on the backward-compatible monitor, for lack of a better idea.
0 comments