TerminalIODoc.tioga
Christian Jacobi, September 23, 1985 1:54:47 pm PDT
Last Edited by: Christian Jacobi, August 8, 1986 12:04:48 pm PDT
TerminalIO
CEDAR 6.1 — FOR INTERNAL XEROX USE ONLY
TerminalIO
Christian Jacobi
© Copyright 1985, 1986 Xerox Corporation. All rights reserved.
Abstract: Package which implements a single, shared terminal viewer.
Created by: Christian Jacobi
Maintained by: Christian Jacobi <Jacobi.pa>
Keywords: IO, Terminal, Ascii
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
TerminalIO loads the package
TerminalIO open opens a TerminalIO viewer
TerminalIO NewLog closes the log file and opens a new log file
2. Client Usage
Sequential IO for "terminal and keyboard"
All processes share one terminal 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 modules and their comments.
TerminalIO.mesa: main definitions.
TerminalIOExtras.mesa: additional procedures.
These additional procedures are not included in TerminalIO.mesa because the implementation looks so ugly that I might be tempted to remove them again.
The following convention should 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.)