Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!RICHTER.MIT.EDU!krowitz
From: krowitz@RICHTER.MIT.EDU (David Krowitz)
Newsgroups: comp.sys.apollo
Subject: Re: Processes in GPR_$borrow mode
Message-ID: <8905251341.AA06990@richter.mit.edu>
Date: 25 May 89 13:41:34 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 31

I don't believe that you can do what you want with
the released system calls (there may be some 
internal unreleased GPR calls to  accomplish what
you want, however). The whole purpose of GPR_$BORROW
mode was to give the program absolute control over
the screen by borrowing the screen from the display
manager (which normally has control of the screen
and performs the pad/stream operations).

About the only thing I can think of, is that you
could use the TONE calls to cause the node to beep
in a distinctive manner which would alert the user
that there was an incomming message. They could then
exit their GPR_$BORROW mode program and read the
message. We use the QSEND program (available from
ADUS) to pop up messages on the screen of another
node in our network. If the node is running a
program in GPR_$BORROW mode, QSEND will go ahead
and put the message up on the screen and cause the
node to beep, but the message is not visible until
the GPR_$BORROW mode program exits and releases
the screen.


 -- David Krowitz

krowitz@richter.mit.edu   (18.83.0.109)
krowitz%richter@eddie.mit.edu
krowitz%richter@athena.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)