Path: utzoo!utgpu!water!watmath!clyde!rutgers!ucla-cs!zen!ucbcad!ames!necntc!dandelion!ulowell!apollo!mishkin
From: mishkin@apollo.uucp (Nathaniel Mishkin)
Newsgroups: comp.sys.apollo
Subject: Re: GPR and reading from stdin
Message-ID: <39886efe.c366@apollo.uucp>
Date: 7 Jan 88 14:50:00 GMT
References: <8801061945.AA07987@uunet.UU.NET>
Reply-To: mishkin@apollo.UUCP (Nathaniel Mishkin)
Organization: Apollo Computer, Chelmsford, MA
Lines: 61

In article <8801061945.AA07987@uunet.UU.NET> bernie@cidam.rmit.OZ.AU (Bernard Kirby) writes:
>If I initiate the graphics in direct mode then the "input pad" at the bottom
>of the window will accept input read from stdin, however, you still can't 
>read from anyplace in the graphics window. This is annoying, ...
>
>If I initiate the graphics in frame mode the situation improves somewhat, I
>can read some things from stdin, but not all (may be this is a bug
>
>Of course, for borrow mode, it out of the question for this kind of thing.
>
>My questions are:
>
>	a) Is there any simple way of reading and writing using stdin/stdout
>	   when using gpr routines. 
>
>	b) Are there any pad calls that can be used to setup the desired
>	   type of IO.

In short, when doing graphics, input should be obtained using graphics
calls (e.g. "gpr_$event_wait").  I know this seems like a real bummer.
The idea is that the stream I/O model implied by "read", "scanf", etc.
just isn't rich enough to give most graphics programs the kind of control
and information they need to have.  Yes, you could imagine that you'd
read from the stream and get little (say) "graphics input records" that
would have all the graphics information (e.g. what coordinates the cursor
was at when you typed the key; where the mouse just moved to; etc.) but
this is most likely to be a pain since you'd have to parse those records
out of the stream and you'd probably end up writing the equivalent of
"gpr_$event_wait" and calling it instead of (say) "read" directly anyway.

Having said that, I'll give my Extensible Streams (Open Systems Toolkit)
pitch yet again and say that if you *really* want your graphics input
to behave like stream I/O, it can be done, and in any way you like.  I
think some folks at University of Michigan even wrote such a "turn GPR
into stream I/O" type manager.

As far as your partial success with frame mode, well, as you've
assertained, frame mode has other problems.  You really want to use direct
mode.  In general, direct mode is only better than borrow mode in terms
of functionality.

>PS. Take a look at the  line labeled " <===== HOW ????? " in the program
>    above. I have this variable called "n_windows" which is declared
>    locally as (as per an example in one of the manuals)
>
>		short n_windows;
>
>    _NO_ asterisk (*) in front of it at all.
>
>    Then there is the call to pad_$inq_winows, with _NO_ ampersand (&)
>    infront of the variable n_windows.
>    How does n_windows attain the correct value of one (usually) as a result
>    of this call?

"pad_$inq_windows" is declared in "/sys/ins/pad.ins.c" to be "std_$call".  Thus
when the C compiler compiles calls to it, it gives you the extra "&".
-- 
                    -- Nat Mishkin
                       Apollo Computer Inc.
                       Chelmsford, MA
                       {decvax,mit-eddie,umix}!apollo!mishkin