[Coco] Re: [Color Computer] Inkey for Microware C Compiler

[KnudsenMJ at aol.com]

In a message dated 12/7/03 6:52:18 PM Eastern Standard Time, 
johncollyer at zoominternet.net writes:

> int MouseKey(path)
>  int path;
>  
>    Returns a keypress from path if one is available, or returns -1 or -2 if
>  one of the mouse buttons has been pressed (-1=left button, -2=right 
button.)
>  If neither a keypress is ready nor a button is pressed, then it returns a 
0.

Nice routine -- I have one in UltiMusE I wrote years ago that does the same 
sort of thing -- return either a key or a mouse click.  Lets you click the 
mouse in place of hitting ENTER, very handy when you need to type a couple of 
chars and then punch the mouse instead of reaching over to the ENTER key, 
especially with your left hand :-)

>  
>  int MouseKey(path)
>  register int path;

path will almost always be 0, for stdin, but wise not to depend on that.

>   _gs_opt(path,&oldopts);
>   _gs_opt(path,&newopts);
>   newopts.sg_echo=newopts.sg_kbich=newopts.sg_kbach=0;
>   _ss_opt(path,&newopts);

Yes, good to turn off echo IF you plan to do your own character echoing.
May want to leave the Break chars enabled.
 
>   while (TRUE)
>    {
>     if (_gs_rdy(path)>0) /* chars ready? */

This is the function that I use _os9() and I$GetStat to implement directly, 
but might as well use the library fcn if you have it.

>      {
>       read(path,&ch,1); /* get the waiting character */

Note correct use of unbuffered read(), not the buffered stdio getchar().  At 
this low level, mixing with buffered FILE* I/O can mess things up, unless you 
fflush(stdout) before calling this code.

<snip>

>     else   {
>       _gs_mous(path,&mp);
>       if (!mp.pt_valid)
>        continue;

A nit to pick here.  This checks whether your app is "swapped out", i.e., its 
window is not showing since the user has CLEARed to another window.  You want 
to put a fairly long sleep call here, like tsleep(30) for 0.5 second.  When 
the user flips back to this window, there will be a slight delay till the mouse 
"comes alive", but until then, this app is not chewing up CPU by beating a 
dead mouse :-)

The other tests (not quoted here) where a mouse button is pressed, need not 
sleep since the calling process will do something.  Somewhere in the grand loop 
of things, you do want maybe 0.1 sec of sleep, as in tsleep(6), but not so 
much that the cursor is sluggish following the mouse (I'm assuming your code 
refreshes the cursor, though OS9-L2 was rumored to have an auto-follow system 
cursor -- with that, maybe the 1/4 second sleep would be OK).
--Mike K.