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!