|
<NAME>
|
The
Name title indicates the exact string used to identify the Scheme extension.
|
|
|
Action:
|
The
Action field summarizes what the Scheme extension does.
|
|
|
Filename:
|
The
Filename field specifies the name of the source file, including the directory path, containing the implementation of the Scheme extension. The first element of the file path is the component's top-level installation directory.
|
|
|
APIs:
|
The
APIs field indicates the API functions that are called by the extension. These are determined by running the example (refer to the
Example field) through the Scheme AIDE demonstration application and extracting the names of the API functions called by the extension.
|
|
|
This is done by preceding the call to the extension of interest with the
debug:module extension, specifying module name "api"
and level "calls"
as arguments. The resulting list of APIs called is redirected to an output file using the
debug:file extension with a filename argument. API functions called by other extensions in the example are ignored, and are not recorded in this field. Other examples with different surrounding conditions or data may produce a different list of APIs.
|
|
|
Syntax:
|
The
Syntax field describes how the Scheme extension command is entered by the user. Each Scheme extension command is divided into one or more syntax tokens, which may be literals, such as command names or keywords, arguments, or compound tokens. The following font and punctuation conventions are used to represent different components of the syntax:
|
|
|
()
|
Parentheses surround the entire Scheme extension command.
|
|
|
Bold
|
Boldfaced letters denote a syntax literal such as a command name, an option, or a keyword. Keywords that combine bold and normal fonts can be abbreviated to the letters in bold or they may be entered completely. Nonbold arguments are variables that the user determines at the time the command is entered, and whose type is given in the
Arg Types field.
|
|
|
[]
|
Square brackets represent an optional block of syntax elements.
|
|
|
|
|
A vertical bar (logical "or") separating syntax tokens indicates that one or the other token should be specified.
|
|
|
&|
|
An ampersand and vertical bar pair (logical "and/or") separating syntax tokens indicates one or both tokens may be specified.
|
|
|
{}
|
Braces represent a block of syntax elements.
|
|
|
{}*
|
Braces and a superscript asterisk represent a block of syntax elements that is repeated zero or more times. In the following example, zero or more bulge and position pairs must be specified:
|
|
|
|
(wire-body:kwire [vector] position
|
|
|
{bulge position}*)
|
|
|
{}+
|
Braces and a superscript plus sign represent a block of syntax elements that is repeated one or more times.
|
|
|
{}n
|
Braces and a superscript count modifier represent a block of syntax elements that is repeated exactly
n times, where
n may refer to syntax elements that are specified elsewhere in the command.
|
|
|
...
|
Horizontal ellipsis points indicate the omission of several optional items in a list. In the following example, the Scheme extension command takes a list of two or more bodies as arguments:
|
|
|
|
(bool:unite body1 ... bodyn)
|
|
|
Arg Types:
|
The
Arg Types field lists each argument used in the
Syntax field, followed by the type of the argument. Standard Scheme syntax containing parentheses is used for describing a "list" such as
(entity . . .), or a "pair" of items such as
(entity . position). Alternative types are separated by a | "or" symbol, such as
(entity | (entity . . .), which means the argument may be a single or list of entities.
|
|
|
Returns:
|
The
Returns field indicates the type of Scheme object returned by the extension. Returned objects are absorbed by nesting Scheme calls, or their external representation is printed if they are not absorbed.
|
|
|
Errors:
|
The
Errors field lists any common errors that may occur when using this extension.
|
|
|
Description:
|
The
Description field describes the extension, its use, and the surrounding conditions.
|
|
|
Limitations:
|
The
Limitations field lists any limitations to the extension. These can include conceptual limitations, such as operations for which the extension should not be used, real limitations, such as conditions the extension does not support, or platform-specific limitations.
|
|
|
Note
|
The use of term limitations here does not equate to a legal performance standard, rather the term limitation means "additional guidance" regarding the usage.
|
|
|
Example:
|
The
Example field shows an example of the extension and any necessary surrounding Scheme statements that provide context. The example may be followed by an illustration.
|
|
|
Comment lines are indicated by a leading single semicolon
(;). Text lines returned as output by the extension are indicated by leading double semicolons (;;).
|
|
|
In the case of
define statements, the double semicolon output lines may include the result of the
define followed by "=>" and its assumed entity number. The entity number is helpful to know, because subsequent Scheme extensions output the entity number and not the Scheme variable name. However, the actual entity number may be different in your Scheme session. This is why the Scheme examples use the defined variable name as input to subsequent statements. This makes the example more general and useful for copying and pasting into your Scheme session. The actual entity number from your Scheme session could alternatively be used as input instead of the variable name.
|
|
|
The double semicolon is also used in Scheme journal files to indicate returned objects or text from the extension.
|
|
|
Hexadecimal pointer values returned in external representations are shown as
%x, rather than as the actual hex value, which can vary from run to run.
|
|
|
Scheme examples used in the documentation are created and tested by
Spatial. All options are set to the default values, unless modified in the example. Figures that are reproduced in the documentation are created using the
dl:interleaf or
render:interleaf extensions. The figure is scaled as needed for reproduction in the manual.
|
|
|
Prior to running the examples, the Scheme file
manual.scm (shown below) is loaded to provide an isometric view, set the display background, etc. (Spatial loads this file by adding a
load command to the
acisinit.scm initialization file. Refer to the
3D ACIS Getting Started Guide for more information about initialization files.)
|
|
|
;--------------------------------------------------
|
|
; manual.scm
|
|
;
|
|
; This file is used to set up Scheme AIDE for
|
|
; creating and testing examples for documentation.
|
|
; It creates a view, changes the default view from a
|
|
; front to an iso view, etc.
|
|
;
|
|
; To put an image in the Interleaf document: render
|
|
; the image to a file, open the file as a document,
|
|
; size the image to 0.29, and paste the image into a
|
|
; window frame.
|
|
;--------------------------------------------------
|
|
|
(define my_view (view:dl 800 0 545 600))
|
|
|
|
(view:set (position 100 -200 100)
|
|
|
(position 0 0 0)
|
|
|
(gvector 0 0 1) my_view)
|
|
|
|
(view:refresh my_view)
|
|
|
; For Interleaf purposes change the render
|
|
; background to white.
|
|
|
|
(define bg1 (background "plain"))
|
|
(define rdsb (render:set-background bg1))
|
|
(define bsp (background:set-prop bg1
|
|
|
"color" (color:rgb 1 1 1)))
|
|
|
; Set roll back state to return to between examples.
|
|
|
|
(roll:name-state "begin")
|
|
|
|
; Since all rendered images in the documentation are ; created (using Advanced Rendering) with the
|
|
; render:interleaf extension, the following is used.
|
|
|
|
(view:interleaf #t)
|
|
(render:set-mode "full")
|
|
|
|
;--------------------------------------------------
|