I think the point is that multiple monitors are handled differently on Mac
and Windows.
On the Mac, the first model that wasn't a single unit with a built-in fixed
size screen (ie the first model which allowed for the possibility of a
different size screen) also allowed for the possibility of multiple screens.
Hence as soon as there was a way to ask what the size of the monitor was,
there was actually a way to ask how many monitors there were, and for each
one what its rectangle is. The rectangles are not just the dimensions, but
also the relative positions: because multiple monitors can be of multiple
sizes, and arranged in any layout as long as every monitor touches at least
one other monitor on at least one edge, and no monitor overlaps another.
On Windows, support for different screens (and hence a way for programs to
ask how big the screen was) has been there from the beginning; but support
for multiple monitors was added relatively recently. The frig to allow
existing programs to make use of them was therefore that when you asked how
big 'the screen' was, the answer is a single rectangle, which is the
bounding rectangle of all the screens (which might, if the screens are of
different sizes, effectively have 'holes' in it). This is why when using
multiple screens on Windows, you'll often find dialogs are carefully
presented split halfway between the two screens.
On the Mac, the nearest equivalent call has always been to get the size of
the 'main' screen (the one with the menubar). So there's never been a
function to return the bounding rect of all screens (if you needed it, you
could get the rects of each screen and calculate it yourself, but it would
be considered a misleading and rarely useful concept, since it could have
holes in it).
So it makes perfect sense that if you ask for "the rect of the screen" on a
Windows machine, the answer is likely to be the bounding rectangle of all
monitors; and that if you ask the same question on a Mac, the answer is
likely to be the rect (starting at 0,0) of the main monitor.
I know nothing about *nix - but I'd guess that X-windows resembles the Mac
situation more closely?
It would be trivial to write an XFCN to return this information for the Mac
- in fact I'd be stunned if there isn't one already out there (check the
Dartmouth or Rinaldi collections) (you can use XFCNs on MetaCard, right? -
or is that a Revolution-only feature?). But ideally there would be a
built-in, cross-platform solution. The simplest would be if "the
screenrect" was, when appropriate, a list of one or more rectangles (one per
line). That's obviously a small potential compatibility break - OK for
anyone that parsed it by items, but liable to cause an error (when used on a
multi-monitor system) if a script assigns it directly to be the rect of some
other object. (But why would anyone do that?)
So second option would be second function ("the screenrects()"?) that would
return such a list. I note from the Revolution documentation, and I assume
this is also true for MC, that the screenrect returns the value noted at
startup, not reflecting any changes made while the app was running. Perhaps
this limitation too could be lifted if a new function was provided.
Ben Rubinstein | Email: [EMAIL PROTECTED]
Cognitive Applications Ltd | Phone: +44 (0)1273-821600
http://www.cogapp.com | Fax : +44 (0)1273-728866
Archives: http://www.mail-archive.com/[email protected]/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
