Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ucbcad!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac
Subject: Re: MultiFInder+MultiVideo+MultiMachine
Message-ID: <22461@ucbvax.BERKELEY.EDU>
Date: 8 Jan 88 23:25:37 GMT
References: <22366@ucbvax.BERKELEY.EDU> <22367@ucbvax.BERKELEY.EDU> <7138@apple.UUCP>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 30

In article <7138@apple.UUCP> dgold@apple.UUCP (David Goldsmith) writes:
>So any loop you have (such as the one David gave) should contain the
>following test:

>if (((**gd).gdFlags & (1<<screenDevice)) &&
>	(((**gd).gdFlags) & (1<<screenActive))) {
>	... whatever you want ...
>}

>around whatever you want to do for each active monitor.


Now I'm confused. David Goldsmith is quite right, Stew Rubenstein also
pointed this out, but on the same page of Inside Mac Vol5. where
GetDeviceList() and GetNextDevice() are described is the call:

TestDeviceAttribute()

which is an easy and clean way of testing the gdflags. Surely, it is
better to use the call than testing the bits directly.
--------------------------------------------
Bug report:

I keep my modal dialogs entirely on the CRT screen that holds the
window the modal dialog refers to.  I do this by scanning th device list
looking for the one that holds my window, then constraining my modal
dialog ot be entirely on that screen (and if it is the main screen, I
check to keep it out of the way of the menu.) Apple itself got this check
wrong in the default menu definition procedure: menus that are supposed to
be drawn on a second video screen don't get drawn.