TerminalIODoc.tioga
Christian Jacobi, September 23, 1985 1:54:47 pm PDT
Last Edited by: Christian Jacobi, March 27, 1992 3:23 pm PST
Bob Krivacic, February 18, 1991 2:52 pm PST
TerminalIO
PCEDAR 10.1 — FOR INTERNAL XEROX USE ONLY
TerminalIO
Christian Jacobi
© Copyright 1983, 1986, 1987 Xerox Corporation. All rights reserved.
Abstract: Package which implements a single, shared log viewer.
Created by: Christian Jacobi
Maintained by: Christian Jacobi <Jacobi.pa>
Keywords: IO, Terminal, Ascii, Log
XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304
For Internal Xerox Use Only
1. Interactive usage
Sequential IO for "terminal and keyboard"; ideal for logging actions.
The module keeps a log file: TerminalIO.log.
Commander Commands
Require PCedar TerminalIO TerminalIO Load the package
User Profile Options
TerminalIO.TimeMsg: 30
Interval in minutes to make periodic time messages; read once on initialization only.
2. Client Usage
Sequential IO for "terminal and keyboard"
All processes share one log viewer.
All procedures must not be called from inside a viewers-repaint or a TIP-notify procedure.
All output procedure might be delayed while input is pending.
Look at the definition module and its comments.
TerminalIO.mesa
The following convention must be followed by clients:
Input is requested only as result of an interactive user action.
3. Rationale
This module is well suited for certain kind of logging actions or giving feedback.
If independent applications feedback always as immediate answer to an interactive action, it is very reasonable to share a viewer for this feedback. That is where this module should be used most.
On the other side this package probably should not be used when independent processes or applications make output at random times; in this case, these applications should better have a feedback area of their own.
This module takes care of the existence, creation and interactive deletion of its viewers; clients will not get any errors or signals on outputs. Inputs may raise UserAbort or TimeOut, but only where mentioned in the definitions module.
The input routines are a poor man's routines; they require the user to really make the input (or abort) because the package will not do any other operations until the input is finished. For simple applications this might even be what is wanted. It is specially conveniant for applications which are extended on the fly to have an easy IO handling module; Extensions are eased if they need not deal with viewer creation of the main application.
The strict following of the input convention guarantees that the user is not forced to switch his awarness to a different application at random times.
The fact that users can always abort input guarantees that client programs can not lock other clients out of doing feedback. (The private procedure AddLock is the exception; thats why this procedure is private.)