🚀 go-pugleaf

    davism@KCGL1.eng.ohio-state.edu :
    [...]
    If anyone out there running 5.5-2 in field test could speak to whether the
    SMG$READ_LOCATOR call is documented and/or fixed, I'd appreciate it.

Lots of SMG$ routines were fixed in V5.5-2, but still no mention of
SMG$READ_LOCATOR.  Note that this routine has two additional arguments -
a timeout argument (5th) and a parse routine (6th).  The parse routine
receives the keyboard id, locator response (string), row, column and keycode.
You might be able to use the parse routine to make things behave more the way
you want them to.

If you are using this routine at a time when you expect the user to use the
mouse for input, this routine works fine.  I wish I could read a mouse event
from an SMG$ application which is dynamic in nature - eg., time gets updated
once per second, etc.  The ANSI sequence of asking for locator information
and waiting for the response is quite restrictive for such applications.  I
have at times wondered if one couldn't query the mouse driver for mouse button
press events.  That way an application could receive asynchronous notification,
much as an Xwindows application would.

SMG$ does have a few things which are quite useful in the DECterm environment
which aren't documented, besides SMG$READ_LOCATOR.  Try using any of the user
renditions when writing text to a display - you get a limited set of colors.

JaW

jwilkinson@hmcvax.claremont.edu