Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!ucbvax!husc6!endor!olson From: olson@endor.harvard.edu (Eric K. Olson) Newsgroups: comp.sys.mac Subject: Re: Two Monitors on a Mac II? Message-ID: <4070@husc6.harvard.edu> Date: 19 Feb 88 00:39:14 GMT References: Sender: news@husc6.harvard.edu Reply-To: olson@endor.UUCP (Eric K. Olson) Organization: Lexington Software Design, Lexington, MA Lines: 53 In a recent article Robert George Johnston, Jr. writes: > > Putting two different monitors side by side with different dimensions and >color abilities is perfectly alright. The Monitors cdev will allow you to set >the orientation of the two monitors to each other and they will act as an >extension of each other. If you are displaying a color picture on the color >monitor and drag half of it over to the B&W monitor, the B&W will usually show >mostly black pixels. For single color text or pictures, there really isn't a >problem. It's no problem for the system software, true. But I have been running a SuperMac Spectrum and an Apple Monochrome (both 8-bit, although variously set to different bit depths) side by side for about 4 months. Very little thrid-party software that does Mac II specific stuff (like greyscale) works properly with two monitors (virtually all software that is written for 128K ROMs works fine on either (or straddling) screen). Image Studio (a greyscale Paint program) lets you move the window to the non-menu-bar screen but then doesn't work right until you move it back. PixelPaint works better but the tools stop working. All pop-up menus (like the .h files in LSC) always appear on the screen with the menu bar, as close as possible to the postition they should be in (i.e., pinned against the edge of the screen nearest the screen they should have popped up in). Programs (like Screensavers) that compare mouse position to screenBits.bounds don't get the real corners of the screen, making it difficult to put the mouse in the lower left corner when there's no left edge on that screen (DragWindow and other system calls have less of a problem through "judicious comparison of the rectangle passed"). The default ZoomBox code (TrackZoomBox or something like that) starts seeming a little dumb when clicking in the zoombox of a window on the SuperMac screen makes it fill the Apple Monochrome screen [I propose that it should cycle through the bounds of all attached screens and finally recycle to the non-zoomed size]. Note that with the advent of multiple screens, coordinates for windows can be negative. The upper left of the menu bar is always at Global Coordinate (0,0), but not always at the leftmost of the logical screen. It is possible to write code that does greyscale on the Mac II with arbitrary screens correctly, but it is damned difficult and my own code doesn't do it quite right yet. For most uses, the multiple screen implementation is the cleanest I have ever seen (especially considering it's compatible with software that had no idea this was coming) and extremely convenient. Currently, many Mac-II specific programs work correctly only on the screen with the menu bar (called the "Main GDevice"), but this will doubtless change as we all become smarter about programming the Mac II. -Eric "We're writing tomorrow's software yesterday." Eric K. Olson olson@endor.harvard.edu harvard!endor!olson D0760 (Name) (ArpaNet) (UseNet) (AppleLink)