Service Manuals, User Guides, Schematic Diagrams or docs for : xerox sdd memos_1978 19780814_Recording_And_Playing_Back_Selections_In_Stored_Command_Sequences
<< Back | HomeMost service manuals and schematics are PDF files, so You will need Adobre Acrobat Reader to view : Acrobat Download Some of the files are DjVu format. Readers and resources available here : DjVu Resources
For the compressed files, most common are zip and rar. Please, extract files with Your favorite compression software ( WinZip, WinRAR ... ) before viewing. If a document has multiple parts, You should download all, before extracting.
Good luck. Repair on Your own risk. Make sure You know what You are doing.
Image preview - the first page of the document
>> Download 19780814_Recording_And_Playing_Back_Selections_In_Stored_Command_Sequences documenatation <<
Text preview - extract from the document
XEROX
BUSINESS SYSTEMS
Systems Development Division
August 14, 1978 XEROX SDD A!CII~
I have read and und@ntvtJ~
To: Advanced Design and User Prototypes Group
Pages
Beviewer~
______
- ...
----- Date__To
---
._
-==~
# of pages_ _Be:t " If S 41>- /6t
c: Larry Clark
From: Dave Smith, Bob Shur / SD at Palo Alto
Subject: Recording and playing back selections in Stored Command Sequences
Filed on: star )macro- selections.bravo
This memo addresses some issues concerning the representation of selections in Star's stored
command sequences. It deals with Star and the real implementation, not necessarily the Desktop
prototype. (How the prototype differs from this theory, if at all, is undecided.) These issues
may continue to evolve as we gain more experience with a working system, real or prototype.
The following topics are discussed: issues involved in recording selections, the syntactic form of a
recorded selection, the identification of Star objects, defining variables, the pattern- matching
algorithm for using variables, recordable objects and actions, and playback.
Recording selections in Star
It is clear that there is 1i ttle difficulty in recording or playing back command operators. We
simply record the text on a key cap, e.g. "MOVE", or in a menu, e.g. "CLOSE". On playback, we
have a case statement which dispatches on the command string.
For operands to commands, however, the situation is more interesting. There are two questions:
What is an adequate representation for a selection?
How can we generalize the selection representation to include variables?
A comparison with Bravo illustrates these questions. Bravo has very few objects, mainly windows
and characters. Star, on the other hand, has many kinds of objects (printers, file drawers, mail
boxes, calculators, ...), many kinds of text containers (documents, fields, text scrolls), and many
kinds of primitive objects (characters, frames, graphic symbols, tables, ...). Star actions can deal
with any of these objects and be recorded doing so. Therefore we need a flexible representation
that can encompass Star's richness.
2
Bravo always starts a macro execution (replay) at the Alto executive level. It requires that the
playback state be identical to the define state. Bravo records exactly what is done at define time,
e.g. exactly which characters in which windows are selected. This means that Bravo can never
execute a recorded typescript on anything but the original document. (If you try, you'll be sorryl
However Bravo can run short startup and quit macros on different documents.) In Star we
attempt to ease this restriction by a powerful representation and by permitting users to define
"variables" at record time and to "bind" these variables to different values at playback time. The
most interesting and challenging problem for stored command sequences is how to use these
variables. When the user makes a selection that is "related" to a previously defined variable,
what do we record?
After conversations with most of ADUPG, we have designed solutions to these problems. (These
solutions will likely undergo refinement, but things seems to be progressing.) The first solution
is a complete syntactic description of recorded selections. The description incorporates the
needed power. The second solution is a pattern matching algorithm describing how and when to
generalize the parts of a selection.
One thing to note is that while a selection representation may be quite long, it is a simple
structure made up of simple parts, and therefore is amenable to manipulation by a machine.
Syntax of recorded selections
The overall representation of any selection in Star can be described in a single line:
SelectionRepresentation ::= "[" VariablePart* ConstantPart* "]"
Here "*" means "any number of", but at least one variable or constant part must be present. Also
the parts of a selection are separated by commas. The detailed description of the parts follows .
VariablePart .. - ObjectType Variable
ConstantPart ObjectType ObjectIdentification
ObjectType Function Teon
"Folder"
"Document"
"Record File"
"Frame"
"Footnote"
"Field"
"Table"
"Row"
"Column"
GraphicElement
''Text Scroll"
"Record"
"Text"
3
I "Caret"
1,- "X-Y"
I "Sheet"
I "Option"
Functionlcon .. - "Directory"
"File Drawer"
"Printer"
"Calculator"
GraphicElement .. - "Point"
"Symbol"
"Group"
"Multiple"
"Guiding"
"Pinned"
Variable .. - n*" Number
Object Identification
.. - Name (icon)
Name (document- unique) (field)
Number (documen t- unique) (frame, footnote)
Number (frame- unique) (table, graphic element,
tex t scroll)
Number (table- relative) (row, column)
CharNumber ":" CharNumber (document/scroll- relali ve) (text)
CharNumber (document/scroll- relative) (text, caret)
Integer Integer (desktop/frame- relative) (x- y)
Name (of property/option sheet) (sheet)
Name (of property/option) ( option)
Name (record fi le- unique) (record)
Name Number (record file- unique) (record clement)
GraphicList (graphic group,
multiple selection)
Name .. -
Number ::=
Integer .. -
CharNumber .. - Number
no"
"last"
4
GraphicList .. - "(" GraphicSymbol {"," GraphicSymbol}* ")"
GraphicSymbol .. - GraphicElemcnt Variable
GraphicElement ObjectIdentification
"Field" above includes two kinds of fields, form fields and form letter sequences, which are not
distinguished in command sequences. "Text" includes formatting characters, words, sentences,
paragraphs and frames. "Row" and "Column" can occur in either order in table identifications.
x- Y points can be negative, indicating a place to the left or above a frame origin; they are in
units of screen dots.
Examples of recorded selections:
[File Drawer "Dave Smith" #] # represents a 64- bit Pilot number
[Printer "Daisy" #]
[Folder "Purchase Orders" #]
[Record File "Help Data Base" #]
[Document "My Memo" #]
[Document "My Memo" #, Frame 1]
[Document "My Memo" #, Footnote 3]
[Document "My Memo" #, Field "subject"]
[Document "My Memo" #, Frame 1, Table 1]
[Document "My Memo" #, Frame 1, Table 1, Row 5]
[Document "My Memo" #, Frame 1, Table 1, Column 3]
[Document "My Memo" #, Frame 1, Table 1, Row 5, Column 3]
[Document "My Memo" #, Frame 1, Table 1, Column 3, Row 5]
[Document "My Memo" #, Frame 1, Symbol 14, Guiding 1]
[Document "My Memo" #, Frame 1, Symbol 14, Guiding 1, Pinned 3]
[Document "My Memo" #, Frame 1, Group 15, Guiding (Symbol 6, Point 1),
Pinned (Symbol 6, Point 2)]
[Document "My Memo" #, Frame 1, Multiple (Symbol 3, Symbol 7, Group 15),
Guiding (Symbol 3, Point 3)]
[Document "My Memo" #, Frame 1, Scroll 4]
[Document "My Memo" #, Frame 1, Scroll 4, 1:15]
[Document "My Memo" #, Text 23:45]
[Document "My Memo" #, Text l:last]
[Document "My Memo" #, Caret 23]
[Document "My Memo" #, Caret last]
[Document "My Memo" #, Frame 1, X - Y 100 - 25]
[X- Y 100 200]
[Record File "Parts Inventory" #, Record "Part Name" 1]
Note that the object selected is implicilly described by this representation. However the
representation is unambiguous and determinable. For example, the fact that a Pinned point is
included in a graphic selection means that a control point is selected; a Guiding point without a
Pinned point means that a whole graphic symbol is selected.
5
Star object identification
It has become clear that every selectable object in Star, with the exception of text characters,
needs a permanent, invariable identification. This was briefly addressed in version 4 of the
Functional Spec., but many objects were left out. The above list is more complete, though it may
still have one or two omissions. What many of these identifications should be has crystallized
only after working with the Desktop prototype and thinking about scenarios.
Each object identification can be thought of as either "absolute" or "relative", depending on
whether or not it needs other object identifications to be a complete description. All inter-
document objects (icons and only icons) have "absolute" identifications; i.e. they can stand alone.
Examples:
[File Drawer "Dave Smith" #] # represents a 64- bit Pilot number
[Printer "Daisy" #]
[Folder "Purchase Orders" #]
[Record File "Help Data Base" #]
[Document "My Memo" #]
These identifications are unique. No more description need be given in order to unambiguously
resolve them. On the other hand, all intra-document objects have "relative" identifications; they
need additional information in order to be unambiguously resolved. Examples:
[Document "My Memo" #, Frame 1]
[Document "My Memo" #, Footnote 3]
[Document "My Memo" #, Field "subject"]
[Document "My Memo" #, Frame 1, Table 1]
[Document "My Memo" #, Frame 1, Symbol 14, Guiding 1]
[Document "My Memo" #, Frame 1, Scroll 4]
[Document "My Memo" #, Text 23:45]
[Document "My Memo" #, Caret last]
[Record File "Parts Inventory" #, Record "Part Name" 1]
The question arises as to the extent to which users will have to know about and deal with these
identifications. I think stored command sequences will be successful only if the answer is
"almost nothing". The proper approach is that all of these identifications are system generated
and stored; USers will not understand them or deal with them. (It is simply not practical to
expect them to be able to change "Symbol 14" to "Symbol 23"; it's unlikely any of LIS could!) The
only exception is that the names associated with icons, fields and records are user- generated and
therefore are user- changable.
Each identi fication requires an entry in the object's internal data structure. For intra- document
objects, a single word (16 bits) should be enough. For icons, the Pilot number is used. In every
case, with the exception of text, all object identiJications have the Jollowing characteristics:
◦ Jabse Service Manual Search 2024 ◦ Jabse Pravopis ◦ onTap.bg ◦ Other service manual resources online : Fixya ◦ eServiceinfo