My apologies in advance for the length of this reply; but I think I want 
to make this exchange part of a FAQ! :-)

First, to address Tedd:
>I have dual monitors and I _never_ program an application specifically for
>the "other" monitor. I only use dual monitors for a larger desk top while I
>program (I like several windows open at once and I like irritating windoze
>users).
>
>Personally, I don't think it wise to program applications for monitors
>other than the main monitor any way. What's the point? So, with that said,
>I don't think that one has to address multiple monitors. And, I'm not sure
>as to what problems are refereed to in the first portion of this email. I
>haven't had any problems with FNJN II and dual monitors.

I'd bet my video card that your monitors are both color, both set to at 
least 640x480, and if one is "better" than the other, that it's the one 
you have the menubar on. :-) In this case, even with FnJnIII or 
"whatever" that deals with multiple monitors (Game Sprockets, for one) 
_you_ won't see any difference; everything will "start up" on your main 
monitor. Just for fun, set your "main" monitor to the lowest resolution 
and bitdepth it's capable of, and the other to the highest/deepest. Now 
run a commercial game. Does it still come up on the main monitor? Does it 
refuse to run?

The programming I'm referring to isn't to "force" something to another 
monitor, but just to use it "correctly" if it's there. Although we do (or 
did) have one list member who has his second monitor in a different 
_room_ from the first, in a specialised situation...

Back to the original message:

>>The multi-monitor stuff is "finishing off" what Ross started in II, as I'm
>>real tired of having software not-work-quite-right on my dual monitor
system,
>>when it's so easy to do it "the right way"!
>
>It may seem easy to do it the right way to you, but that's because you have
>multiple monitors. Some of us only have a single Mac with a single monitor to
>work with. I'm sure you're thinking "So what. Just pop these FNs in your
>program and you're set", but that doesn't cut it. I have way too many
>questions. Is my program supposed to ask what monitor the person wants to 
>use?

You _can_ do that, if you wish, but it generally isn't necessary. 
Hopefully though, I can answer at least most of your questions...

I've never asked the user "which monitor do you want to use", although 
the hooks are in FnJnIII's routines to be able to do that. I always use 
the "primary" monitor UNLESS I absolutely can't run on it.

>Or do they somehow select that some other way? What happens if they somehow
>have both monitors set up as one big monitor? What happens with my ALRTs and
>DLOGs? In ALRTs, ResEdit gives you 3 choices of where to display the ALRT;
>Main screen, Parent window, Parent window's screen. I've already seen what
>happens if I have an ALRT set to display in the Parent window or the Parent
>window's screen if there's no window open when the ALRT is displayed
>(crashola). I'm sure there's more I can't think of right now.

Generally there are two ways to get a "multiple monitor" setup; one is 
video mirroring, which simply means you see the same thing on two 
monitors. That one is irrelevant, as your program only sees one monitor. 
So for you to be concerned, they'll _always_ have them set up as "one big 
monitor", effectively.

I haven't seen the ResEdit issue, but generally ALRTs will continue to 
appear on the "main monitor" in either the "Alert position" or centered; 
you _could_ use the "on parent window's screen" option, and you could 
certainly test it on a single-monitor system; if it's going to crash with 
two, it'll crash with one.

DLOGs just come up on the main monitor, wherever you set them, as far as 
what I've ever done... although I'm sure I could (and should) have 
investigated this further.

>There's far too many things I am unsure about to even think about attempting
>it without ever being able to test it. There's no way I'm going to send out a
>program with multiple FNs in it that I've never tested. Here's a good one.
>What happens when a user who has just gotten another monitor starts asking me
>questions about how to get the program working on the second monitor? My
>answer would be "I don't know". I doubt if he would even want to try my
>program on the other monitor once he hears that.

When you add a second monitor on a Mac system, it's "just there". To get 
a program working on it, that was working on one monitor on the same 
system before, you just drag the window over to the other monitor. As 
long as the color depth of the second monitor is the same or better, the 
user will see _no_ difference; she can even leave one of your windows 
half on one monitor and half on another. (Try this in WinNT! "Blue Screen 
of Death" time!) If your program saves window locations, you probably 
should provide some way to "override" this, so if they go back to a 
one-monitor system, they don't have windows hanging out in empty space 
where they can't get the mouse. Otherwise, the person that could already 
run your program, who adds a monitor, is of concern only if they add a 
monitor that _won't_ run your program, and they make it their "primary" 
monitor. More below.

>Again, all this may seem simple and minor to you, but that's because you have
>a multi monitor setup. I've never even seen one.

My first "2nd monitor" was a Radius Full Page Display (monochrome) on a 
hot-off-the-assembly-line Mac SE. I've been spoiled rotten ever since, 
and just automatically figure in the price of a second monitor & card (or 
plan on reusing existing ones) any time I upgrade my Mac. It _literally_ 
is the difference between night and day when debugging; I let FB's 
debugger have all of my "left" monitor, while the program is running on 
the "right" monitor. No toggling back and forth, watching one frame of 
each. Same with MacsBug, although it's a little trickier. At this 
instant, I've got Emailer on the right screen, and the FnJnIII orders 
database on the left, so I can read the mail and retype the relevant 
parts without covering up the window I'm not "in".

It was moving that FPD to a IIci though that got me convinced software 
needed to be "smarter". Too much stuff said "I'm sorry, I require 256 
colors to run", right in the middle of that FPD - and four inches from a 
perfectly good 640x480, 256 color monitor.

Anyone who has a "spare" monitor sitting around, hooked to an unused PC 
or something, should seriously consider spending the $2-300 it takes to 
get a decent video card. Game players also, because the cards are 
accellerated, and games will play better through them than the on-board 
video; even on a G3!

However, I well understand that $300 is a considerable expense, and if 
you _don't_ already have another monitor, that quickly becomes at least 
$500; 1/3 of a new G3. So... _can_ you write multiple-monitor-aware 
software on a single monitor system? I think so, and be confident of the 
results.

Here's the writeup I came up with today when I didn't have your email in 
front of me to be "specific"...

-----------------

There are several things to look at here, but this really _is_ easier 
than you think, and code can be "safely" written on a one-monitor 
system...

There are three cases of multiple-monitor systems your code should 
consider.

First is the case where the "primary" monitor (the one with the menu bar) 
_is_ adequate for your program's needs, and so is the "secondary" 
monitor. In this case, there is nothing to do any differently than you 
normally would; you can build your windows on the primary monitor, and 
the user can move them about at will with no problems. No code changes 
are required at all to deal with this case, although it'd be nice to at 
least know it exists...

Second is the case where the "primary" monitor is adequate, but the 
"secondary" monitor is NOT. (Such as a monochrome monitor when your 
program requires color.) I generally don't worry about this case, just 
letting the program continue to run on the primary monitor. If the user 
drags my windows over to the monochrome monitor, they're taking their 
chances on whether everything will "work as expected" or not. Obviously 
any graphics will look terrible; but still, the code _shouldn't_ crash. 
This is exactly the same scenario, code-wise, as the user launching your 
program, then after you've passed all of the "can I run" checks, changing 
the monitor bit-depth to 1 (or anything less than you need). You can test 
for this quite easily on a one-monitor system, and you don't need any 
code from FnJnIII to deal with it. (Although most don't, sadly including 
myself most of the time...)

Third is the "annoying" case; the "primary" monitor is _not_ adequate, 
but the secondary monitor is, and your code erroneously reports that you 
can't run. Most people with their monitors set up like this have hit this 
situation quite frequently, and have switched their "best" monitor to the 
primary position (case 2), but a few can't do this, for whatever reason. 
(Most likely, it's a Powerbook with an external monitor, where the LCD 
isn't 640x480 and can't get there, or is monochrome, but the external 
screen is fine. Although I think most newer PBs can make the external the 
"primary".) Here, FnJnIII can help.

I'm going to "give away the secret" here, since anyone who wants to spend 
a few hours or days writing and debugging the code to save the $29.50 is 
welcome to do so! What you have to do is look at _all_ attached monitors 
when you do your initialization routine, before deciding the user doesn't 
have the hardware needed. If you find that a "non-primary" monitor will 
work for what you need, but the primary won't, you have to accomodate 
this in three ways. (Which "fail safe", so doing all of this won't hurt 
if the test passes, or with one monitor.)

First, you can't use FB's built-in "window centering" routine (using 0,0) 
when you build a window, but instead must use real coordinates that will 
place the window in the correct position on the correct monitor. Second, 
if you build windows at some "fixed" location, say (50,80)-(250,180), 
you'd need to use the calculated offsets 
(50+scrnLeft%,80+scrnTop%)-(250+scrnLeft%,180+scrnTop%) instead. (On a 
one-monitor system, these globals will be 0...)

BUT! All of this is what the FnJnIII function "LocateWindow" does; you 
set your rectangle to where you'd want the window on a one-monitor 
system, call LocateWindow, and it changes the rectangle for you; your 
next line is the WINDOW statement. No keeping track of offsets, and it 
does work (correctly) with (0,0), centering the window on any monitor for 
you.

Third, you can't use SYSTEM(_scrnWidth) and SYSTEM(_scrnHeight) for 
anything, because they'll lie to you and only report the primary monitor. 
FnJnIII _could_ very quickly be modified to set globals gScrnWidth% and 
gScrnHeight% for you to use instead (on a one-monitor system, they'd be 
the same as the SYSTEM versions). I don't do that myself, because the 
only time I use the SYSTEM calls is to create a full-screen window, and 
that rectangle is available with one "blockmove"...

All of this is set based on the 'best' monitor FnJnIII finds when you 
call FN whichMonitor; if that's the only monitor, that's fine. 
"whichMonitor" does a bit more than just a "yes/no" check though; it 
_can_ tell you the "biggest", "currently deepest", "deepest possible", 
"leftmost", "rightmost", "top", and "bottom" monitors as well as the 
"primary" monitor. If your program requires 832x624 and the "best color 
available", you can quickly set everything up for the deepest monitor 
that's at least that big, with preference given to the primary monitor if 
it "ties" with another. On the other hand, if no monitor fits the 
requirements you pass in, you can either change to lower "specs" and try 
again, or just put up your "sorry Charlie" message.

You could even get creative and build a region that included _all_ the 
monitors, for those animation effects that you want to fill all available 
space. (There used to be a flight sim, I forget the name, that supported 
3 monitors; the view out the 'left side" of the cockpit was put on the 
left monitor, likewise the right, with the center one for the instrument 
panel and "forward" view...)

Because these routines work just fine even on a one-monitor system (and 
you can check the values quite easily in the debugger, to make sure 
they're the same as you'd get without the code) you can be 99% sure that 
if they work for you on your system, they'll work on a two (or three, or 
four, or eight...) monitor system. Just call the routines when needed, 
use globals instead of the built-in FB values if you must, and that's it! 
If in doubt, or just nervous about it, I'd be happy to spend a few 
minutes checking your FnJnIII-using finished program on my system to make 
sure nothing bizarre happens.

Look at it this way; if adding one or two function calls at 
initialization, and one before each WINDOW build, _might_ allow your code 
to function on more Macs, and _won't_ hurt anything on a single-monitor 
system, then you're ahead!

If anyone has any further questions (whew!) send them to me "offline", so 
as not to take up bandwidth here. I'll add the best/most common to this 
mess, and let jonathan clean it all up as another FAQ...

Bill

P.S. Regardless of whether you decide to "handle" case 3 or not, or you 
use FnJnIII or not, PLEASE don't build windows at "negative" values just 
assuming they'll be invisible to the user... my second monitor is to the 
_left_ of my main monitor, and I've seen a couple of programs that build 
"work areas" out there, and get _real_ confused if I click on them and 
they become the active window. It doesn't take much to actually check and 
make sure there is no monitor where you're building your dummy windows, 
or better yet, use gWorlds instead!