Beruflich Dokumente
Kultur Dokumente
Reference Manual
AVEVA Solutions Limited
PML Disclaimer
1.1 AVEVA does not warrant that the use of the AVEVA software will be uninterrupted, error-free or free from
viruses.
1.2 AVEVA shall not be liable for: loss of profits; loss of business; depletion of goodwill and/or similar losses; loss of
anticipated savings; loss of goods; loss of contract; loss of use; loss or corruption of data or information; any
special, indirect, consequential or pure economic loss, costs, damages, charges or expenses which may be
suffered by the user, including any loss suffered by the user resulting from the inaccuracy or invalidity of any data
created by the AVEVA software, irrespective of whether such losses are suffered directly or indirectly, or arise in
contract, tort (including negligence) or otherwise.
1.3 AVEVA shall have no liability in contract, tort (including negligence), or otherwise, arising in connection with the
performance of the AVEVA software where the faulty performance of the AVEVA software results from a user's
modification of the AVEVA software. User's rights to modify the AVEVA software are strictly limited to those set out
in the Customisation Manual.
1.4 AVEVA shall not be liable for any breach or infringement of a third party's intellectual property rights where such
breach results from a user's modification of the AVEVA software or associated documentation.
1.5 AVEVA's total liability in contract, tort (including negligence), or otherwise, arising in connection with the
performance of the AVEVA software shall be limited to 100% of the licence fees paid in the year in which the user's
claim is brought.
1.6 Clauses 1.1 to 1.5 shall apply to the fullest extent permissible at law.
1.7. In the event of any conflict between the above clauses and the analogous clauses in the software licence
under which the AVEVA software was purchased, the clauses in the software licence shall take precedence.
PML Copyright
Copyright and all other intellectual property rights in this manual and the associated software, and every part of it
(including source code, object code, any data contained in it, the manual and any other documentation supplied
with it) belongs to, or is validly licensed by, AVEVA Solutions Limited or its subsidiaries.
All rights are reserved to AVEVA Solutions Limited and its subsidiaries. The information contained in this document
is commercially sensitive, and shall not be copied, reproduced, stored in a retrieval system, or transmitted without
the prior written permission of AVEVA Solutions Limited. Where such permission is granted, it expressly requires
that this copyright notice, and the above disclaimer, is prominently displayed at the beginning of every copy that is
made.
The manual and associated documentation may not be adapted, reproduced, or copied, in any material or
electronic form, without the prior written permission of AVEVA Solutions Limited. Subject to the user's rights, as set
out in the customisation manuals to amend PML software files contained in the PDMSUI and PMLLIB folders and
any configuration files, the user may not reverse engineer, decompile, copy, or adapt the software. Neither the
whole, nor part of the software described in this publication may be incorporated into any third-party software,
product, machine, or system without the prior written permission of AVEVA Solutions Limited, save as permitted by
law. Any such unauthorised action is strictly prohibited, and may give rise to civil liabilities and criminal prosecution.
The AVEVA software described in this guide is to be installed and operated strictly in accordance with the terms
and conditions of the respective software licences, and in accordance with the relevant User Documentation.
Unauthorised or unlicensed use of the software is strictly prohibited.
© Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved. AVEVA shall
not be liable for any breach or infringement of a third party's intellectual property rights where such breach results
from a user's modification of the AVEVA software or associated documentation.
AVEVA Solutions Limited, High Cross, Madingley Road, Cambridge, CB3 0HB, United Kingdom.
PML Trademark
AVEVA and Tribon are registered trademarks of AVEVA Solutions Limited or its subsidiaries. Unauthorised use of
the AVEVA or Tribon trademarks is strictly forbidden.
AVEVA product/software names are trademarks or registered trademarks of AVEVA Solutions Limited or its
subsidiaries, registered in the UK, Europe and other countries (worldwide).
The copyright, trademark rights, or other intellectual property rights in any other product or software, its name or
logo belongs to its respective owner.
Software Customisation Reference Manual
Revision Sheet
Contents Page
Reference Manual
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
Summary of Objects, Members and Methods . . . . . . . . . . . . . . . . . 2:1
Object Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1
Methods Available to All Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:3
Forms and Menus Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:4
Members Contained by All Gadgets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:4
Summary of Gadget-Specific Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:5
Gadget Syntax Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:6
Rules for Presenting and Using Syntax Graphs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:6
Setting Up Gadget Anchoring: <fganch> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:7
Setting Up Gadget Docking: <fgdock> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:7
Setting-Up the Gadget’s Position: <fgpos> and <fgprl> . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:8
Setting Up the Gadget’s Width and Height: <vshap>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:9
Setting Up the Gadget’s Tagwidth (TEXT, TOGGLE and OPTION): <fgtagw> . . . . . . . . . 2:10
Setting Up the Gadget’s 2D Screen Position: <xypos> . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:10
Object Type Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:11
ALERT Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:11
ARC Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:12
ARRAY Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:21
BANNER Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:25
BAR Gadget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:26
BLOCK Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:28
BOOLEAN Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:28
PMLSECURELOGIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:133
PMLUSERLOGIN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:134
POINTVECTOR Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:134
POSITION Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:137
POSTEVENTS Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:142
PROJECT Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:143
PROFILE Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:144
RADIALGRID Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:154
REAL Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:156
REPORT Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:161
RTOGGLE Gadget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:164
Section Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:166
Section Plane Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:168
SELECTOR Gadget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:171
SESSION Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:174
SLIDER Gadget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:176
STRING Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:178
STATE ............................................................ 2:185
TABLE Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:185
TEAM Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:187
TEXT Gadget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:188
TEXTPANE Gadget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:191
TOGGLE Gadget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:193
UNDOABLE Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:195
UNIT Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:196
USER Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:198
VERIFY ............................................................ 2:199
ViewFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:199
VIEW Gadget: ALPHA Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:201
VIEW Gadget: AREA View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:202
VIEW Gadget: PLOT View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:204
VIEW Gadget: VOLUME Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:206
XYPosition Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:209
1 Introduction
This manual is the Reference Manual for the AVEVA Programming Language, PML.
It is intended for users who are already familiar with PML. Users who are starting to use
PML should refer to the Software Customisation Guide, which should be used together with
this manual.
There are two versions of PML, the older one, known as PML 1, and the newer one, known
as PML 2. PML 2 has been written specifically for creating and customising the AVEVA GUI,
and this manual is mainly concerned with PML 2.
However, PML 2 has not completely replaced PML 1, and there are some tasks which are
carried out more efficiently using PML 1 facilities. In particular, this manual describes the
PML 1 expressions package, which is used within PDMS; for example, for writing rules and
defining report templates. You should also refer to the Database Management Reference
Manual.
This manual contains:
• A list of PML 2 Objects, Members and Methods. For the Forms and Menus objects, the
command syntax relating to the objects is included.
Note: Many properties of Forms and Gadgets that were previously set using commands
should now be set using the Form or Gadget methods. In general, the only
commands described are those which have not been replaced by methods. If you
are maintaining old code, you may need to refer to the edition of the AVEVA Software
Customisation Guide dated October 1995, which describes the old syntax in detail.
Bar
Button
List
Option
Para
Slider
Text
Text-pane
Toggle /Rtoggle
View Alpha
View 2D
View 3D
Numeric Input
Container
Combobox
Frame
Line
Selector
View:Plot
SetEditable X X
SetFieldProperty X
SetFocus X X X X X X X X X X X
SetHeadings X
SetLine X
SetPopup X X X X X X X X X X X X X X X
SetRange X
SetRows X
SetSize X X X X
SetTooltip X X X X X X X X X
SetValue X
Shown X X X X X X X X X X X X X X X X X X X
ShowPopup X
Subtype X X X X X X X X X X X X X X X X X X X
Type X X X X X X X X X X X X X X X X X X X
ValidateCall X
‘gname’. Sometimes they are fictitious e.g. ‘tagtext’, but more helpful than just
“text” and easier to understand than a reference to, say, <fgtag>.
4. Continuous vertical and horizontal lines without a “ + “ symbol represent flow lines of
the graph.
1. The presence of a “*“ symbol in a vertical line indicates that the allowed direction of
traverse is upwards.
2. The presence of a “<“ symbol on a horizontal indicates that the allowed direction of
traverse is backwards.
3. The symbols “.“, “/“, “ ‘ “ are just cosmetic to help the graph to look better.
.---<-------------.
/ |
>-- <fganch> -----------+-- ANCHOR --+--+- Left ----. |
| +- Right ---| |
| +- Top -----| |
| ‘- Bottom --+---+---*
| |
+---- None ----|
‘---- All------’-->
The subgraph <fgprl>, shown below, sets the gadget position relative to another gadget or
the form’s extent. For example, you can use it to position a gadget halfway across the width
of a form.
The <fgtagw> graph supports both the simple ‘tagtext’ setting and/or the specification of the
maximum width of any tag.
If the tag width is not explicitly given then it is assumed to be the number of characters in the
‘tagtext’ string multiplied by the horizontal grid size (the notional character width for the font).
You can specify the tag width without specifying any tagtext at definition time; this can be
added at run time.
Methods
EndPosition(POSITION)
Through(POSITION)
Complement()
Cord(REAL)
CordHeight(REAL)
StartPosition(POSITION)
AnglePosition(REAL)
AngleDirection(REAL)
EndTangent()
AngleTangent(REAL)
StartTangent()
XYOffset(POSITION)
Near(POSITION)
Proportion(REAL)
Chord()
Length()
ChordHeight()
Intersections(LINE) Intersections(PLANE)
Intersections(ARC)
Tangents(POSITION)
Tangents(ARC)
On(POSITION) 8
On(POSITION) 9
Methods
Members
Command
Methods
Command
The BAR command creates a bar menu within a form definition.
The recommended way to create menu fields on the bar is to use the bar's Add() method.
bar
!this.bar.add ( 'Choose', 'Menu1')
!this.bar.add ( ' window', 'Window' )
!this.bar.add ( 'help', 'Help' )
Note: The use of the two special menu names ’Help’, which adds a system help menu that
calls the online help; and ‘Window’, which adds a system Window menu that lists all
the displayed windows.
Methods
Methods
None of these methods modifies the original object.
Member
Methods
None of these methods modifies the original object.
Members
Methods
Command
The BUTTON command defines a button, and specifies its position, tag or pixmap, callback
text and control attribute.
You can define the BUTTON to be either PML-controlled, or core-code controlled using the
gadget qualifier attribute control type, with values ‘PML” or “CORE”.
The files defining any pixmaps should be specified in the form's default constructor method
using the gadget's AddPixmap() method.
A Button type Linklabel provides a purely textual button presentation, often used to indicate
a link to some application item, e.g. a hyperlink to a file, a link to an associated form. An
Example of the Linklabel gadget is shown on the example form in Fold up Gadget Link
Example Form with Fold-up panels, NumericInput and Linklabel gadgets.
The tag text is shown in a different colour to all other gadget's tag text. The link label gadget
highlights by underlining when the mouse cursor passes over it. Pressing it causes a
SELECT event to be raised and runs any associated call back.
Note:
.--------<-------.
/ |
>-BUTTON gname -+- LINKLabel -+-- tagtext -------|
| +-- <fgpos> -------|
| +-- CALLback text -|
| +-- TOOLTIP text --|
| +-- <fganch> ------|
| +-- <fgdock> ------|
| +-- CORE ---------* Core managed gadget
| | .------<-----.
| |/ |
| +- FORM fname -|
| +- <vshap> ----*
| |
| +- TOOLTIP text -.
| '----------------'-->
|
| .--------<----------.
+-- TOGGLE -./ |
'-----------+- tagtext -----------|
+- <fgpos> -----------|
+- CALLback text -----|
+- TOOLTIP text ------|
+- <fganch> ----------|
+- <fgdock> ----------|
+- CORE --------------| Core managed gadget
+- BACKGround <colno>-|
+- PIXMAP <vshap> ----*
| .------<-----.
|/ |
+- FORM fname -|
+- <vshap> ----*
|
+- OK -----.
+- APPLY --|
+- CANCEL -|
+- RESET --|
+- HELP ---|
'----------+- TOOLTIP text -.
'----------------'-->
Note: It is bad practice to place one gadget on top of another. This may lead to gadgets
being obscured.
The Pixmaps associated with Button gadgets can be changed after the gadgets have been
displayed on a form.
Method syntax is:
AddPixmap( !pixmap1 is STRING )
AddPixmap( !pixmap1 is STRING, !pixmap2 is STRING )
Where: !pixmap is a string holding the file pathname of the required .png file, e.g.
%pmllib%\png\camera.png
!pixmap1 shows the Un-selected state of the gadget, and pixmap2 shows the Selected
state.
Notes:
1. It is recommended that when you define the gadget you set its size to encompass the
largest pixmap which you will later add. Failure to do this may give rise to unexpected
behaviour.
2. Historically you could add a third pixmap which was used when the gadget was de-
activated. This practice is no longer necessary as the gadget pixmapped is
automatically greyed-out on de-activation.
Methods
Note: Users can set the scope on a collection object to the whole MDB by not setting a
scope or by using the ClearScope( ) method.
Methods
2.5.12 COLUMNFORMAT
The column object defines the way in which a column of a table object is populated.
The formatting of a column should be separate from the column definition itself and be held
within the report object used to extract data from a table object. This will allow the same
table to have many different reports produced from it, without the need to regenerate the
table.
Methods
Members
Methods
Command
.-------<-------.
/ |
>-- COMBObox gname -+- <fgtagw> ------|
+- <fgpos> -------|
+- <fganch> ------|
+- <fgdock> ------|
+- CALLback text -|
+- TOOLTIP text --|
+- NORESELect ----|
+- ZEROSELection -|
+- CORE ----------* Core managed gadget
| .-------<-------.
|/ |
+- SCRoll int ----|
+- <vwid> --------*
|
+- TOOLTIP text -.
'----------------'-->
When the ComboBox is editable, with the drop-down list closed, the user can search for a
required option by typing the first few letters into the display field and clicking the down-
arrow. The list will open with the first matching option highlighted. This is useful for large
lists.
Behaviour
The COMBOBOX command is a combination of an option list and an editable text display
field similar to a windows combobox. It shares most of the properties and methods of the
Option gadget.
Combo gadget has editable display text field (default) and so supports scroll width.
Combobox does not support display of pixmaps.
Note: It is bad practice to place one gadget on top of another. This may lead to gadgets
being obscured.
Unselected Events
Option gadgets support UNSELECT events. Typically when a field in the dropdown list is
selected, an UNSELECT event is raised for the previously selected field (if any) and then a
SELECT event is raised for the new field.
Notes:
1. UNSELECT events are not notified to PML unless an open callback has been specified
(so that SELECT and UNSELECT events can be differentiated).
2. Typically the UNSELECT action allows Appware to manage consequences of
deselection for any dependent gadgets or forms.
3. We recommend that you do not change the option gadget's selection programmatically
in an UNSELECT event.
Members
Methods
GetPickedPopup( ) MENU Returns the last picked popup menu for the
gadget.
Command
The Container gadget allows the hosting of an external Control, e.g. a PMLNet, control
inside a PML defined form. It allows the user to add an external .Net control, which may
raise events that can be handled by PML. In order to customise the context menus of the
.Net control, the Container may have a PML popup menu assigned to it. This is shown when
the .Net control raises a 'popup' event.
.--<-----.
/ |
>---- CONTAINER gname -+- NOBOX ---|
+- INDENT --*
|
'- PMLNET/CONTROL -+- handle -.
'----------|
.----<------------------------*
|
| .----<-----------------.
|/ |
+-- tagtext -------------|
+-- <fgpos> -------------|
+-- <fganch> ------------|
+-- <fgdock> ------------*
|
+-- <vshape> -.
'-------------'-->
Notes:
1. By default the Container will be enclosed in a box, but you can select NOBOX or
INDENT.
2. Only PMLNet controls are supported.
3. 'handle' is the integer token identifying the control.
4. Positioning must be specified before size (<vshape>).
5. Dock and Anchor are supported to allow intelligent resize behaviour. The enclosed
control must support resizing and is usually set as Dock fill, so that it follows size
changes of the Container.
Methods
Methods
2.5.17 DB Object
Members
Methods
These methods may be used in the following ways (in all cases !!CE is assumed to be a DB
DATABASE element and !!CE.Name is a STRING object containing the element’s name).
Examples:
!D = OBJECT DB(!!CE)
!D = OBJECT DB(!!CE.Name)
!D = !!CE.DB()
!D = !!CE.Name.DB()
Command
Methods
Members
Members
Methods
None of these methods modifies the original object.
Methods
Methods
Methods
None of these methods modifies the original object.
Members
Methods
Commands
SETUP FORM
A form definition is introduced by the SETUP FORM command and terminated by a
corresponding EXIT command. Once in Form Setup mode you can call any commands for
defining the form’s properties, creating a menu bar (see BAR object), main and popup
menus (see MENU object) and any gadgets which it is to own.
Once-only form attributes are entered as part of the SETUP FORM command line;
modifiable attributes are entered as contents of the form.
You can define the FORM to be either PML-controlled, or core-code controlled using the
qualifier attribute control type, with values ‘PML” or “CORE”.
that allows users to change the default layout mode for Setup form. This can be used to help
test any existing appware which is using setup form !!formname . . ., in either mode to
determine which forms need layout adjustment.
NOALIGN
The gadgets BUTTON, TOGGLE, TEXT, OPTION, single line PARGRAPH fit within 1
vertical grid unit and are by default drawn with their Y-coordinate adjusted so that they would
approximately centre-align with an adjacent BUTTON. This pseudo-alignment introduces
small errors in all but a few circumstances and prevents accurate controlled layout.
NOALIGN prevents this (historical) gadget auto-alignment.
Use NOALIGN in conjunction with PATH RIGHT (the default path) and HALIGN CENTRE,
as it gives a better layout, with fewer surprises.
Note: It is bad practice to place one gadget on top of another. This may lead to gadgets
being obscured.
The commands to set modifiable attributes are described after the syntax graph.
.---------------<---------------------------.
/ |
>--SETUP FORM fname --+-- MAIN -----+-------------------------------|
+-- DOCUMENT -+- FLOAT -----------------------|
| ‘-------------------------------|
+-- DIALOG ---+- DOCKing -+-------------------|
| |- Left ---. |
| | |- Right --| |
| | |- Top ----| |
| | ‘- Bottom -‘--------|
| |- RESIzeable ------------------|
| ‘-------------------------------|
+-- BLOCKingdialog -+- RESIzeable ------------|
| ‘-------------------------|
+-- VARCHARS ---------------------------------|
+-- FIXCHARS ---------------------------------|
+-- AT <xypos> -------------------------------|
+-- SIZE val val -----------------------------|
+-- NOQUIT -----------------------------------|
+-- NOALIGN ----------------------------------|
+-- CORE -------------------------------------*
| .---<------.
|/ |
+-- <form> --* form contents
‘—EXIT -->
TITLE
Defines the form title.
CANCELCALL
This command defines the callback string which is executed whenever the form is
dismissed from the screen via the CANCEL button or the QUIT/CLOSE control on the
window title bar.
Note: This command overrides the callback string on the CANCEL button.
CURSORTYPE
When a screen cursor enters a view, the view gadget determines what cursor type should
be displayed initially, and what type will be displayed during different types of graphical
interaction. You can specify the initial setting for the cursor type using this command.
Note: You cannot specify an initial cursor type for VOLUME views.
Note: There are other cursor types that are for AVEVA’s use only.
ICONTITLE
Defines the title for the icon when the form is minimised.
INITCALL
Defines the callback string that is executed each time the form is displayed. This callback is
usually run to check the validity of showing the form and to initialise gadget values.
OKCALL
Defines the OK callback string for a form. It is executed whenever the form is dismissed
from the screen via its OK button or that of an ancestor.
PATH
Defines the direction in which a sequence of new gadgets is to be added to a form. The path
setting remains until you give another PATH command. Used with HALIGN, HDISTANCE,
VALIGN, VDISTANCE.
Defaults: Path right, Hdist 1.0, Valign top, Vdist 0.25, Halign left
HALIGN
Works in conjunction with PATH and HDISTANCE. Defines how a newly added gadget
should be aligned horizontally with the preceding gadget.
HDISTANCE
Works in conjunction with PATH and HALIGN. Defines how a newly added gadget should be
spaced horizontally with respect to the preceding gadget.
VALIGN
Use in conjunction with PATH and VDISTANCE. Defines how a newly added gadget should
be aligned vertically with the preceding gadget.
VDISTANCE
Works in conjunction with PATH and VALIGN. Defines how a newly added gadget should be
spaced vertically with respect to the preceding gadget.
Define the form, its gadgets, methods and layout are specified (usually in a
'.pmlfrm' file)
Load the form definition is read by PML and the form's constructor method is
run
Show the form's INITialisation event is raised, and the display process is begun
Activate the form and its contents is created by the window management system
and is activated (actually displayed) and the FIRSTSHOWN event is
raised
Kill the form's KILLING event is raised and then the form is destroyed. It is no
longer known to PML
Notes:
1. Load, Activate and Kill only happen once in the life of a form
2. Show and Hide may happen repeatedly
3. The form's Constructor is run once only
4. The FirstShown event only happens once
5. INIT is raised for every Show
The PML user can define callbacks to service any or all of the above events. These will
typically be open callbacks supported by form methods. They can be assigned within the
form's Constructor method (recommended), or within the form's Setup Form . . . Exit block.
FIRSTSHOWN callback
Typically assigned in the Constructor by
!this.FirstShownCall = '!this.<form_method>'
The purpose is to allow the user to carry out any form actions which can only be completed
when the form is actually displayed. There are a variety of circumstances where this arises
and it is often difficult to find a reliable solution. A couple of examples are given below.
Commands which manipulate form, menu or gadget visual properties, executed from a PML
macro, function or callback may not happen until control is returned to the window
manager's event loop. For example, in the application's start-up macro the command
sequence show !!myForm … hide !!myform will result in the form not being displayed, but
also not becoming known at all to the window manager. Attempts to communicate with this
form via the External callback mechanism (possibly from another process) will not work.
This can be rectified by doing the '!this.hide()' within the FIRSTSHOWN callback, because
the form will be guaranteed to be actually displayed (and hence known to the window
manager), before it is hidden.
It is sometimes difficult to achieve the correct gadget background colour setting the first time
the form is displayed. This can be resolved by setting the required colour in the
FIRSTSHOWN callback.
KILLING callback
Typically assigned in the Constructor by
!this.KillingCall = '!this.<form_method>'
The purpose is to notify the form that it is being destroyed and allow the assigned callback
method to destroy any associated resources, e.g. global PML objects which would
otherwise not be destroyed. This may be necessary because PML global objects will survive
an application module switch, but may not be valid in the new module.
Notes:
1. The callback method MUST NOT carry out any modifications to the Gadgets belonging
to the form or to the Form itself (e.g. don't show or hide the form). Attempts to edit the
form or its gadgets may cause unwanted side effects or possible system errors.
2. Form callbacks designed for other Form events (e.g. CANCEL, INIT) are rarely suitable
as killing callbacks.
3. Restrict form and gadget operations to querying.
Members
Members
Methods
Command
The FRAME command defines a frame gadget.
A frame is a container which owns and manages any gadgets defined within its scope,
including other frames.
The frame gadget properties visible and active will automatically apply to all of its children,
but will not overwrite their corresponding property values.
There are five types of FRAME: NORMAL, TABSET, TOOLBAR, PANEL and FOLDUP
PANEL.
• A NORMAL frame can contain any type of gadget, including other frames. It also
behaves as a radio group, with radio buttons defined by the set of RTOGGLE gadgets
that it directly contains. See the entry RTOGGLE Object for more about the RTOGGLE
gadget.
• A TABSET frame can contain only tabbed page FRAMEs; you cannot nest them and
they are not named.
• A TOOLBAR frame can contain only a subset of gadget types: BUTTON, TOGGLE,
OPTION, and TEXT. It must have a name and can appear only on main forms.
.---<-------.
/ |
>--FRAME gname -+- TOOLBAR -+- tagtext -+- <toolbar> -* toolbar contents
| ‘—- EXIT -->
| .---<--------.
| / |
+- TABSET -+-- <fgpos> ---|
| +-- <fganch> --|
| +-- <fgdock> --|
| +-- <vshap> ---*
| | .---<--------.
| |/ |
| +-- <tabset> --| tabbed frame contents
| +-- NL --------*
| ‘-- EXIT -->
+- PANEL --+----------.
| ‘--INDENT--|
+- FOLDUPpanel -------| .---<--------.
|/ |
+-- tagtext ---|
+-- <fgpos> ---|
+-- <fganch> --|
+-- <fgdock> --|
+-- <vshap> ---*
| .---<--------.
|/ |
+-- <formc> ---* form contents
‘-- EXIT -->
where the sub-graphs <toolbar>, <tabset> and <formc> define the allowable gadgets
and layout commands available within the specific container type.
Note: The graph <formc> defines the normal content of a form, all gadget types (except
BAR) are allowed. There are restrictions on frame gadget types as defined below.
Note: Frame gadgets defined anywhere within the TABSET frame can only be of type
NORMAL, not TOOLBAR or TABSET frames.
NORMAL frames defined directly within the TABSET frame, will appear as tabbed
pages within it.
Notes:
1. After choosing frame type Panel, the contents is defined in the usual manner.
2. Tagtext can be specified, but it is never displayed.
3. The panel has no visible enclosing box, unless the INDENT option is specified when it
will have a 3D indented appearance.
4. Panel supports all the attributes of a Normal Frame including the notion of a radio
button group.
Notes:
1. After choosing frame type FoldUpPanel, the contents is defined in the usual manner.
The panel can contain the usual PML gadgets except another FoldUpPanel.
2. Separate events are raised after expanding or collapsing the panel.
For frames which are FoldUpPanels, 'HIDDEN' and 'SHOWN' events are raised whenever
the user interactively folds or unfolds the panel. These events are only fired if a PML open
callback is defined.
This ensures that the SELECT event, used to signal selection of a radio button within a fold-
up panel can still be handled by simple (non-Open) callbacks.
To manage FoldUpPanels which are also radio groups, then you must supply an open
callback so that you can differentiate the panel's SELECT, HIDDEN and SHOWN events.
Set-up Methods
Name Purpose
.selection() Creates an empty selection object .
Query Methods
2.5.28 IDList
The IDList object provides features for the accessing and manipulation of elements in an
IDLIST database element.
Elements in the IDlist object must be significant elements, in the following sense. The
database element reference supplied to the constructor is examined to see if it either:
• Owns a valid design drawlist element; in which case the supplied element is added to
the idlist object.
• Is owned by a drawlist element, in which case the significant owner is added to the
idlist.
Elements below the level of the design drawlist element cannot be manipulated via this
object.
Set-up Methods
Name Purpose
.idlist(DBREF) Creates an PML IDlist object from the given DBREF of an
IDLIST. Searches up the ownership hierarchy until a
significant element is found, and adds this to the Idlist.
Before adding an ADDE, the object will check whether there is an 'active' ADDE in the list -
this is an ADDE for the identical element, without an intervening REME for the same object.
If so, it will not add it again. Similarly for REMEs.
When removing ADDEs or REMEs, the system will start from the bottom of the list and work
backwards removing the requested entry.
Access Methods
Command
The Line gadget gives the ability to display horizontal or vertical lines to separate groups of
gadgets on a form, for increased clarity of intent. The line's presentation reflects the colour
of the current Windows scheme.
.-------<---------------.
/ |
>--- LINE gname -+- tagtext ---------------|
+- <fgpos> ---------------|
+- <fganch> --------------|
+- <fgdock> --------------*
|
+- VERTical ---.
| |
'- HORIZontal -'- <vshap> -->
Example: The form 'Nested Frames' above shows a vertical LINE and a horizontal LINE.
The code snippet below shows the construction of the innermost frame f3.
frame .f3 'f3'
vdist 0.2
hdist 0.5
toggle .t1 'Toggle 1' at x 2
line .horiz 'H-Line' Horiz wid.f3 hei.t1
toggle .t2 'Toggle 2'
line .vert at xmin.f3 ymin.f3+0.5 Vert wid 2 hei.f3
exit
Notes:
1. The tag text is never displayed.
2. Line does not apply to toolbars.
3. The graph <vshap> allows the line's width and height to be set either specifically or in
terms of other gadgets on the form.
4. Setting the height for a Horizontal separator or the width for a Vertical separator causes
the line to be drawn across the middle of the implied area. This allows for equal spacing
on each side of the separator line. Otherwise a default width or height is assumed.
5. The Dock and Anchor attributes allow the Lines to be dynamic and respond to
interactive changes in form size.
6. The gadget is not interactive and has no associated value.
Members
Definition Methods
None of these methods modifies the original object.
EndPosition
Direction(DIRECTION)
StartPosition
OnProjected(POSITION) 9
On (POSITION) 9
Proportion(REAL)
Intersection(LINE)
Near(POSITION)
Figure 2:24. Table -48: LINE Object Methods that Return REALs
Length()
Distance(POSITION)
Distance(LINE)
ExtendEnd(REAL)
To(POSITION)
SetLengthStart(REAL)
ExtendStart(REAL)
Towards(POSITION)
From(POSITION) SetLengthEnd(REAL)
Parallel(POSITION)
Offset(DIRECTION, REAL)
Projected(PLANE)
Union(Line)
Overlap(Line)
Members
Definition Methods
These methods do not modify the original object.
Orientation
YSpacing
Z Y
Position
XSpacing
Snap(POSITION)
Snap(LINE)
GridPoint(REAL, REAL)
Within(POSITION)
Plane()
Within(POSITION)
XYOffset(POSITION)
Members
Methods
Column Headings
The number of columns is deduced from the List's data. If the user specifies a set of (1 or
more) column headings before the list is populated, then this will determine the number of
columns. If no headings are pre-specified then the number of columns is deduced from the
display text (Dtext) of the List's first data field. This provides upwards compatibility for
existing Appware using single column lists.
A List gadget's headings can be replaced after the list has been populated. If the new
headings specify the same number of columns then the headings are replaced but the List's
data fields and selection remain unchanged. If the number of columns is different, then the
list is replaced by an empty list with the new headings.
Invoking the Clear() method will clear the list's data fields and rebuild the current headings.
There are two methods for defining a List's column headings:
The data fields can be set using the List's DTEXT member or its Add methods, where a
row's Dtext string can be a set of TAB separated column sub-strings for populating multiple
columns. Alternatively you can use the SetRows or SetColumns methods.
Unselect Events
Single choice List gadgets support UNSELECT events. Typically when a field is selected, an
UNSELECT event is raised for the previously selected field (if any) and then a SELECT
event is raised for the new field. An UNSELECT event is raised whenever a selected field is
interactively deselected.
Notes:
1. UNSELECT events are not notified to PML unless an open callback has been specified
(so that SELECT and UNSELECT events can be differentiated).
2. Typically the UNSELECT action allows Appware to manage consequences of
deselection for any dependent gadgets or forms.
3. We recommend that you do not change the List's selection programmatically in an
UNSELECT event.
Command
The LIST command defines a single-choice or multiple-choice list gadget, and specifies its
position, tag, number of columns and callback text. Also defines the area (width and height)
in which the displayed part of the list will appear.
The arrays defining the display texts and replacement texts for the list options are usually
set in the form's default constructor method.
.-------<--------.
/ |
>- <flist> - LIST gname -+- <fgtagw> ------|
+- <fgpos> -------|
+- <fganch> ------|
+- <fgdock> ------|
+- CALLback text -|
+- TOOLTIP text --|
+- CORE ----------* Core managed gadget
|
+- MULTiple --------.
| .-------<-------. |
|/ | |
+- NORESELect ----| |
+- ZEROSELection -* |
‘-------------------‘- <vshap> +- TOOLTIP text -.
‘----------------‘->
Note: The TOOLTIP keyword can be given at two different places in the syntax.
Members
Methods
Note: The Sessions() method provides information required for remote expunging. This
method will cause daemon activity for locations other than the current location.
Member
Command
Member
Methods
None of these methods modifies the original object.
!D = OBJECT MDB(!!CE)
!D = OBJECT MDB(!!CE Name
!D = !!CE.MDB()
!D = !!CE.Name.MDB()
Command
Members
Methods
Members
Methods
Note: Setting the Active and Visible properties of a SEPARATOR field will affect the
implied group of fields comprising the SEPARATOR field and all subsequent fields up
to but not including the next SEPARATOR field.
For each of the Add() methods above, you can use a special field-type to indicate
that the field is managed by core-code i.e. CORESEPARATOR, CORECALLBACK,
COREFORM, COREMENU, and CORETOGGLE.
You do not need to specify callback functions for core-managed fields.
Command
MENU objects are owned by FORM objects, and can be created within form setup mode. It
is also possible to add a new menu to an existing form - usually for context sensitive popup
menus.
The recommended way to create a menu and its fields, typically within form setup mode, is:
!menu = !this.newmenu( ‘Menu1’, ‘MAIN’ )
!menu.add( ‘CALLBACK’, ‘save’, ‘<callback>’, ‘field1’ )
!menu.add( ‘FORM’, ‘save asº’, ‘saveForm’, ‘field2’ )
Note:
• Each menu is either part of the Main menu system or part of the Popup menu system,
but cannot belong to both.
• If you specify neither POPUP nor MAIN at setup time, then the menu’s usage is initially
unknown. The system will attempt to deduce the usage type from the first action that
references the menu.
• Menus in the Main system can only appear once. That is, a main system menu cannot
be a sub-menu of several menus.
• Menus in the Popup system may appear only once in a given popup tree, but may be
used in any number of popup trees.
• A menu cannot reference itself, either directly as a pullright of one of its own fields or be
a pullright of another menu in its own menu tree.
• You can add menu fields with an optional field-name. If you do not specify a field-
name, then you will not be able to refer to it later.
• You can use a special field-type to indicate that the field is managed by core-code i.e.
CORESEPARATOR, CORECALLBACK, COREFORM, COREMENU, and
CORETOGGLE.
You do not need to specify callback functions for core-managed fields.
An alternative is to use the MENU command, followed by the menu’s ADD commands and
terminated by the EXIT command. The full syntax is shown below:
.-----<-----.
/ |
fmenu>-+- ADD -+- fieldname -|
+- CORE ------*
+- SEParator -------------------------------.
‘- dtext -+- rtext -------------------------|
+- MENU -- gname -----------------|
+- FORM -- fname -----------------|
+- CALLback -+- rtext ------------|
| ‘--------------------|
‘- TOGgle -+- rtext -. |
‘---------+- SELected -|
‘------------‘-->
mdrRoutePoint
Radius Real Set the fillet radius Valid only if this isn't an
of route point external geometry type
route point. If there is
DB element owned then
sets the filet radius,
otherwise sets the
radius inside the object
mdrRoute
mdrBaseManager
mdrConnectionManager
mdrConnectionGraph
mdrConnectionPoint
Members
Methods
Command
The NumericInput gadget allows numeric input within a specified range, with given
granularity.
The Up/Down arrows control incrementing and decrementing the displayed value by the
specified increment, within the range. Additionally it is possible to type in the required value.
The number of decimal places can also be specified.
.-------<-------------------.
/ |
-- NUMERICinput gname -+- <fgtagw> ------------------|
+- <fgpos> -------------------|
+- <fganch> ------------------|
+- <fgdock> ------------------|
Notes:
1. The tag text is displayed.
2. Default initial value is the minimum value of the range.
3. The range maximum is adjusted to be an integral number of steps.
4. NDP is the number of decimal places. If NDP is zero then all values will be integer.
5. Typed in values will be adjusted to the nearest valid value in the range.
6. The graph <vwid> allows the gadget width to be set specifically or in terms of other
gadgets on the form.
7. It is not possible to provide user formatting of the values displayed by the gadget.
2.5.40 OBJECT
Method
Members
Methods
Command
The OPTION command defines an option gadget and specifies the position, tag or pixmap,
and callback text of the option (or list button) gadget. Also sets the width allowed for
displaying the list options when the gadget is selected.
The arrays defining the display texts and replacement texts for the gadget should be set in
the form's default constructor method.
Notes:
1. Option gadget's display text field is non editable, so doesn't need scroll width (syntax is
in fact in place for backwards compatibility).
.-------<-------.
/ |
>------ OPTion gname -+- <fgtagw> ------|
+- <fgpos> -------|
+- <fganch> ------|
+- <fgdock> ------|
+- CALLback text -|
+- TOOLTIP text --|
+- NORESELect ----|
+- ZEROSELection -|
+- CORE ----------* Core managed gadget
|
+- PIXmap <vshap> -.
'- <vwid> ---------+- TOOLTIP text -.
'----------------'-->
ZeroSelection Property
Option gadgets have a ZeroSelection keyword (similar to that of single choice lists), which
allows it to support the notion of no current selection (previously a selection was
mandatory).
The syntax has been extended with the optional 'ZEROSELection' keyword, e.g.
Behaviour
Note: It is bad practice to place one gadget on top of another. This may lead to gadgets
being obscured.
Unselected Events
Option gadgets support UNSELECT events. Typically when a field in the dropdown list is
selected, an UNSELECT event is raised for the previously selected field (if any) and then a
SELECT event is raised for the new field.
Notes:
1. UNSELECT events are not notified to PML unless an open callback has been specified
(so that SELECT and UNSELECT events can be differentiated).
2. Typically the UNSELECT action allows Appware to manage consequences of
deselection for any dependent gadgets or forms.
3. We recommend that you do not change the option gadget's selection programmatically
in an UNSELECT event.
Members
Methods
None of these methods modifies the original object.
Members
Methods
Command
The PARAGRAPH command defines a paragraph and specifies its position, dimensions (in
units of character widths and line heights), and, optionally tag text or a pixmap. Note that a
paragraph gadget is passive so it ’s callback is never used. A paragraph gadget can have a
tag, but it is not displayed.
You can define the PARAGRAPH to be either PML-controlled, or core-code controlled using
the gadget qualifier attribute control type, with values ‘PML” or “CORE”.
.--------------------<------------.
/ |
>-- PARAgraph gname -+-- <fgpos> ------------------------|
+-- BACKGround <colno> -------------|
+-- <fganch> -----------------------|
+-- <fgdock> -----------------------|
+-- CORE ---------------------------
* Core managed gadget
+- PIXMAP -+- filename -.
| ‘------------‘-<vshap>-->
‘- TEXT text -+-<vshap>-.
‘---------‘-->
Note:
• If a paragraph is to contain text, then its shape will be specified in grid units. The height
is the number of lines of text and the width is typically thought of as the number
characters required. This may be less that the actual string length, because the grid
width is the size of the font notional character width, which is typically smaller than the
largest characters in the font. You may need to specify a few extra grid units to
guarantee to fit variable strings.
• If a paragraph contains text, and no dimensions are specified, the result is a single line
of width (in grid units) equal to the number of text characters. This may not be long
enough to guarantee to fit the specific string, so you may nee to pad out with extra
spaces to avoid truncation.
• If your paragraph is to contain more than one line of text, you must specify a suitable
shape. The text, which can contain newline characters, will be justified in the area
given.
• If a pixmap is specified, the shape of the gadget must be defined and will be in pixels.
Remember to define the pixmap using the paragraph's AddPixmap() method or its
.Val member.
• If the paragraph is to have its contents modified then the text or pixmap file would
normally be specified in the form's default constructor method, rather than in the
gadget definition.
It is bad practice to place one gadget on top of another. This may lead to gadgets being
obscured.
Members
Definition Methods
None of these methods modifies the original object.
Towards(POSITION)
Orientation
Direction(DIRECTION)
Z
Y
Position
X
Near(POSITION)
ThreeDPosition(XYPOSITION)
Intersection(PLANE)
XYOffset(POSITION)
Members
Methods
None of these methods modifies the original object.
Orientation Y Ysize()
Position Z
YSpacing
XSpacing Xsize()
X
2.5.46 PLATFORMGRID
PLATFORMGRID object is used for filling PLTFRM element with certain grid pattern.
2.5.48 PMLSECURELOGIN
PMLSECURELOGIN object is used to control the encrypted command script generation
functionality.
Methods
2.5.49 PMLUSERLOGIN
PMLUSERLOGIN object allows generation of a project entry script only for the currently
logged-in user which means that it does not require entry of username and password.
Methods
Members
Definition Methods
Direction
Position
Offset(REAL)
Through(POSITION)
Towards(POSITION)
Intersection(PLANE)
Miscellaneous Methods
Members
Methods
POSITION A
POSITION X
RADIUS
POSITION B
POSITION X
POSITION B
MAJOR = FALSE
RADIUS
POSITION A
POSITION X
POSITION A
POSITION B
POSITION A
POSITION X
RADIUS
POSITION B
Methods
Members
Methods
Commands
Members
Methods
Table 2: 101. PROFILE Object Methods that Query Profile to Profile Relationships
Orientation
Position
Z
Y
Angles
X
Radii
RadialPosition(REAL, REAL)
Snap(POSITION)
Angle[1]
Snap(LINE)
Radius[1]
Radius[2] GridPoint(REAL, REAL)
Radius[3]
Methods
Methods
Members
Methods
Command
The RTOGGLE gadget (which is very similar to the TOGGLE gadget) is allowed only within
FRAMES. You can added them to a FRAME with the usual positioning and layout
commands. The RTOGGLE gadgets are implicitly numbered 1,2,3… as they are added.
The FRAME gadget can have an assigned callback, which is executed when the radio
group selection is changed, i.e. whenever the user selects an unselected radio-toggle. As
there is only a SELECT action supported, it can be either a simple callback or an open
callback.
.-------<------------.
/ |
>- RTOGgle gname -+- tagtext ------------|
+- CALLback text —-----|
+- <fgpos> ------------|
+- <fganch> -----------|
+- <fgdock> -----------|
+- TOOLTIP text -------|
+- CORE ---------------* Core managed gadget
|
+- STATES offval onval .
‘----------------------+- TOOLTIP text -.
‘----------------‘--->
Note: offval and onval are string values associated with the radio button states unselected
or selected.
Default values are onval = ‘ON’, offval = ‘OFF’.
In order to simplify the task of replacing the use of the (now removed) RADIO gadget by the
radio group Frame gadget, the RTOGGLE gadget’s UNSELECT events are raised only if a
PML open callback has been defined. This allows the simple replacement of TOGGLE
gadgets by RTOGGLE gadgets without the need to modify their callbacks.
Set-up Methods
Display Methods
Query Methods
Set-up Methods
Display Methods
Query Methods
Create Methods
Members
Methods
Command
The SELECTOR command defines a database element selector gadget and specifies its
position, tag, and callback text. Also specifies whether the selector allows a single choice
only or multiple choices and defines the area (width and height) in which the displayed part
of the list will appear. It also allows you to specify which parts of the hierarchy are shown
and whether or not these are updated automatically during database navigation.
.-------<---------.
/ |
>- SELector gname -+-- <fgpos> --------|
+-- tagtext --------|
+-- <fganch> -------|
+-- <fgdock> -------|
+-- TOOLTIP text ---|
+-- CALLback text --*
+-- SINGle -.
+-----------‘- <vshap> DATAbase -+- MEMbers -.
| +- OWNers --|
| ‘-----------+-AUTO-.
| ‘------|
‘- MULTiple <vshap> DATAbase ---+- MEMbers ---------|
|- OWNers ----------|
‘-------------------|
|
.-------<-----------*
|
+-- TOOLTIP text --.
‘------------------‘->
Members
Methods
Note:
• The LocationName member and Location() method imply the location to which the
Session applies. This is normally the current location, except when Sessions at remote
locations have been requested. In a non-Global project, these members and methods
may be unavailable or unset.
• Some ADMIN Sessions in a Global project may apply to another location's system
database. This will be returned as part of the string returned by the Module() method,
if relevant. Other ADMIN Sessions may actually be Global Daemon Sessions. This is
returned as part of the string for the name member.
• Some SESSION object methods have only restricted availability:
• The Modified() method only applies to the current Session at the current
location.
• The Current(), Deferred(), Mode() and Status() methods will not be
implemented for remote Sessions and will return an error.
• The Location(), MDB(), User() and Module() methods are valid for remote
Sessions.
The last three methods will cause Daemon activity for Sessions at remote locations.
• It should be should be observed in using the MDB and USER objects returned by the
MDB() and User() methods for a remote Session. Methods on these objects will
access the currently open system database. Thus the appropriate location's system
database should be opened (using the ADMINISTER SYSTEM command) before
invoking methods on these remotely generated MDB and USER objects.
Command
Members
Note:
• The Val member represents the current value of the slider as a PML REAL (in fact
always an integer).
• The Range member allows the slider range and optionally the step value to be set or
queried. The granularity of the slider movement is determined by the specified step
increment, i.e. a move event is generated at each step increment within the slider’s
range. The range limits must each be an integral multiple of the step size (else an error
is flagged
The RESET action of a form (from reset, CANCEL or QUIT actions) will only reset the
slider current value not other slider properties. So if you redefine the range while a form
is displayed, and press the RESET button, the range will not revert to the previous
settings. You will have to do this from reset button’s callback and/or the form’s
CANCELCALL callback.
• Tick marks, if present, occur at every step value in the range.
Methods
Command
.-------<-------------------.
/ |
>-- SLIDER gname -+- tagtext -------------------|
+- <fgpos> -------------------|
+- CORE ----------------------| Core managed gadget
+- <fganch> ------------------|
+- <fgdock> ------------------|
+- BACKGround <colno> --------|
+- CALLback text -------------|
+- TOOLTIP text --------------|
+- VERTical ------------------|
+- HORIZontal ----------------*
|
| .-------<-------------------.
|/ |
+- RANGE int int -------------|
+- STEP int ------------------|
+- VALue int -----------------*
|
‘- <vshap> -+- TOOLTIP text -.
‘----------------‘-->
Note: The user can specify the range as start, end and optional step and value integer
values.
The <vshap> graph allows the specification of the WIDTH and/or HEIGHT for sliders,
in grid units. The width must be specified for a horizontal slider, and the height must
be specified for a vertical slider. If the other dimension is not specified then a default
size will be assumed.
The tag text is not displayed for a slider gadget.
Methods
Notes:
• The new construct if( !this.attrib.eqNoCase('Name') ) is more efficient than
comparisons of the form if( !this.attrib.upcase() eq 'NAME' ) particularly when the
check fails. It is also more reliable because it doesn't matter what is the case of the
value checked against.
• It may be worth revisiting such checks in the Appware and replacing them with the new
construction as this could fix undiagnosed defects and improve performance!
2.5.65 STATE
The STATE object provides an interface for interrogating and modifying the status of modify
mode. It is only available to Design running in graphical mode.
Methods
Members
Methods
None of these methods modifies the original object.
!D = OBJECT TEAM(!!CE)
!D = OBJECT TEAM(!!CE.Name)
!D = !!CE.TEAM()
!D = !!CE.Name.TEAM()
Command
Members
Methods
Command
The TEXT command defines a text field gadget which supports data values of a given type.
The following can also be specified; Gadget position, tag, size, callback, dock, anchor and
tooltip; maximum length of the string that may be scrolled in the gadget; the name of a
format object which says how a value is to appear as text or be interpreted; that text entered
is not echoed as typed, but appears as asterisks (for entering passwords, for example); that
the field contents can be seen but not edited.
You can define the TEXT object to be either PML-controlled, or core-code controlled using
the gadget qualifier attribute control type, with values ‘PML” or “CORE”.
.--------<-------------.
/ |
>-- TEXT gname --+-- <fgpos> -------------|
+-- CORE ----------------| Core managed gadget
+-- <fgtagw> ------------|
+-- <fganch> ------------|
+-- <fgdock> ------------|
+-- TOOLTIP text --------|
+-- CALLback text -------*
| .---------<---------.
| / |
‘--*-- WIDth integer ----|
+-- SCRoll integer ---|
+---NOEcho------------*
|
‘-- IS --+-- STRING --.
+-- REAL ----|
+-- BOOLEAN -|
‘-- word ----+- FORMAT gvarnm -.
‘-----------------+- TOOLTIP text -.
‘----------------‘-->
The IS word syntax allows for any user defined data type to be used, but this will only work
satisfactorily if a suitable FORMAT object is supplied.
Note: The maximum string length (SCROLL integer) is 256 characters, and the default if
you do not specify a length is 132.
It is bad practice to place one gadget on top of another. This may lead to gadgets
being obscured.
Members
Methods
Command
The TEXTPANE command defines a text pane gadget and specifies its position and tag.
This is a multi-line text input field, allowing the user to enter a number of lines of text (either
directly or using cut and paste). Note that no callback string is allowed with this gadget, as
there is no way of knowing when a user has finished entering text.
The value of a TEXTPANE is its contents, held as an array of strings, where each line is an
element of the array.
You can define the TEXTPANE to be either PML-controlled, or core-code controlled using
the gadget qualifier attribute control type, with values ‘PML” or “CORE”.
The Textpane gadget definition has a new keyword 'FixChars' to force the use of a fixed
width font. This allows the text pane to be used to show simple reports laid out using the
space character.
The chosen font is Courier New (TrueType), because it has a reasonable selection of
character glyphs (nowhere near as extensive as the default variable width font Arial
Unicode MS).
.--------<--------.
/ |
>-- TEXTPane gname --+-- tagtext---------|
+-- <fganch> -------|
+-- <fgdock> -------|
+-- <fgpos> --------|
+-- FIXCHARS -------|
+-- CORE -----------* Core managed gadget
‘-- <vshap> --->
Note: It is bad practice to place one gadget on top of another. This may lead to gadgets
being obscured.
Member
Methods
Command
The TOGGLE command defines a toggle gadget, and specifies its position, tag, and
callback text. Also allows you to specify different text strings for the default ON and OFF
states.
You can define the TOGGLE to be either PML-controlled, or core-code controlled using the
gadget qualifier attribute control type, with values ‘PML” or “CORE”.
.-------<------------.
/ |
>- TOGGLE gname -+- <fgtagw> -----------|
+- PIXMAP <vshap> -----|
+- CALLback text —-----|
+- <fgpos> ------------|
+- <fganch> -----------|
+- <fgdock> -----------|
+- TOOLTIP text -------|
+- CORE ---------------* Core managed gadget
+- STATES text1 text2 -.
‘----------------------+- TOOLTIP text -.
‘----------------‘--->
where text1 corresponds to the OFF setting and text2 corresponds to the ON setting.
Note: It is bad practice to place one gadget on top of another. This may lead to gadgets
being obscured.
Default: Default text strings for the two toggle settings are ‘OFF’ and ‘ON’.
Default state when a toggle is first defined is ‘OFF’; i.e. button
raised.
Pixmaps associated with Toggle gadgets can be changed after the gadgets have been
displayed on a form.
Method syntax:
AddPixmap( !pixmap1 is STRING )
AddPixmap( !pixmap1 is STRING, !pixmap2 is STRING )
Where: !pixmap is a string holding the file pathname of the required .png file, e.g.
%pmllib%\png\camera.png
!pixmap1 shows the Un-selected state of the gadget, and pixmap2 shows the Selected
state.
Notes:
1. It is recommended that when you define the gadget you set its size to encompass the
largest pixmap which you will later add. Failure to do this may give rise to unexpected
behaviour.
2. Historically you could add a third pixmap which was used when the gadget was de-
activated. This practice is no longer necessary as the gadget pixmapped is
automatically greyed-out on de-activation.
Methods
Command
To use this object, first create an undoable object, and define the undoAction(),
redoAction() and clearAction() methods to define the execution strings.
Call the method add() to mark the database and add the undoable object to the undo
stack.
Make the set of changes that you may wish to undo, then call the method endundoable()
to mark the end of the changes.
Member
Methods
General Queries
Enum() REAL Unique integer ID for this unit.
Positive if standard unit.
Negative if compound unit.
Factor() REAL Conversion factor to database
units.
UnitQualifier() STRING Unit qualifier of current units.
Dimension() MEASURE Dimension of unit.
IsStandard() BOOLEAN TRUE if a standard, single, unit.
FALSE if a compound unit (e.g.
kg/m3, m2)
IsNull() BOOLEAN TRUE if units are NONE.
AllDimensions() ARRAY of Set of all standard dimensions.
MEASURES
AllUnits() ARRAY of Set of all named, standard Units.
UNITS
IsImperial() BOOLEAN TRUE if an exclusively imperial
unit (e.g. inch, lb) or a non specific
unit (e.g. second, ohm, degree).
IsMetric() BOOLEAN TRUE if an exclusively metric unit
(e.g. mm, kg) or a non specific unit
used in metric situations.
Note: Derived units (which are units derived from current units of component dimensions
such as area units derived from current distance) and numeric units (no conversion
or unit qualifiers) have empty strings for name, description and qualifier. However
their hash codes are DRVD and NUMB so they can be created using a form as
object unit ('DRVD'). Current units can be set to this using measure.setUnits.
Additionally numeric current units can be set using measure.numeric().
Member
Method
!D = OBJECT USER(!!CE)
!D = OBJECT USER(!!CE.Name)
!D = !!CE.USER()
!D = !!CE.Name.USER()
Command
2.5.74 VERIFY
VERIFY object is used directly to verify that the executing user is on a list of approved users
and is running on an approved host computer, and is running within a given time period. If
the condition is not met the command script terminates immediately with a "Verification
error".
Methods
2.5.75 ViewFinder
The ViewFinder object is to allow the Draft PML user to create a frame in the 3d view which
represents the view frame in the 2d view. Once drawn, the frame can be moved, rotated,
change its representation (but not its size). By manipulating the frame in the 3d view, the
user can modify the view parameters in the current drawing.
Set-up Methods
Name Purpose
.viewFinder(DBREF) Creates a viewfinder object based on the parameters of the
Draft View. The input argument must be the dbref of a valid
View .
.view(DBREF) Sets the associated View object using the DBREF which
must be a valid view
Methods
Query Methods
Members
Methods
Command
The VIEW ... ALPHA command puts you into View Setup mode. You remain in View Setup
mode until you use the EXIT command.
.-------------------------<-------------------------.
/ |
(ALPha)--+- <vshap> -----------------------------------. |
+- CHANNEL -+- COMMANDS -----------------------| |
| ‘- REQUESTS -----------------------‘- NL -*
‘-- EXIT -->
Members
Methods
Command
The VIEW ... AREA command puts you into View Setup mode. You remain in View Setup
mode until you use the EXIT command.
.-------------------------<------------------------.
/ |
(AREa) --+- <vshap> -----------------------------------. |
+- PUT - <sgid> ------------------------------| |
+- LIMits <uval> <uval> - TO - <uval> <uval> -| |
+- SETColour - <colno> -----------------------| |
+- SETHighlight - <colno> --------------------‘- NL -|
+- <cursor> -----------------------------------------|
+- <border> -----------------------------------------|
+-- <pml> -------------------------------------------*
‘-- EXIT -->
DRAFT where <sgid> is either CE (current element) or the name of a 2D graphical element
(e.g., a DRAFT SHEET, VIEW, LIBRARY, etc.) and <colno> is any valid DRAFT colour
definition.
And <cursor> is the syntax for selecting the cursor type, as follows:
>-- CURSortype ---+-- POINTER ----.
+-- NOCURSOR ---|
+-- PICK -------|
+-- PICKPLUS ---|
‘-- CROSSHAIR --‘-->
Members
Methods
Command
The VIEW ... PLOT command puts you into View Setup mode. You remain in View Setup
mode until you use the EXIT command.
.-------------------------<------------------------.
/ |
(PLOT) --+- <vshap> -----------------------------------. |
+- ADD - plot_filename -----------------------| |
+- CLear -------------------------------------| |
+- SETColour - <colno> -----------------------| |
+- SETHighlight - <colno> --------------------‘- NL -|
+- <cursor> -----------------------------------------|
+- <border> -----------------------------------------|
+-- <pml> -------------------------------------------*
‘-- EXIT -->
where:
<colno> is any valid PDMS colour definition.
<cursor> is the syntax for selecting the cursor type, as in 2-19
<border> allows control of zooming and panning as in 2-20
Members
Methods
Command
The VIEW ... VOLUME command puts you into View Setup mode. You remain in View Setup
mode until you use the EXIT command.
Where:
<colno> is any valid DESIGN colour definition; either a colour description or a colour
number
<cursor> is the syntax for selecting the cursor type, as in 2-19
<border> allows control of zooming and panning as in 2-20
Members
Methods
Event Driven Graphics (EDG) describes the AppWare implemented EDG interface, which is
used as the interface between most applications/utilities requiring graphics interaction and
the graphic canvas.
It describes the Public methods and members of the objects used within the system and
how they interact with each other. Also it describes how the AppWare developer can use the
system, write their own handlers, etc. etc.
The EDG interface has been developed to allow a common interface for the AppWare
developer to setup the graphic canvas in an EDG mode, which is relatively simple and
easily extendible. This will allow the developer to concentrate on the development of their
own application without the need to know the underlying mechanism (core implementation)
of the EDG interaction handlers and system.
The system handles all the underlying maintenance of the current events stacked e.g.
associated forms, initialisation sequences, close sequences, etc.
The current implementation of the system has mainly been developed for interaction with
the 3D graphic views in the DESIGN module. However, the interface can be used with any
of the modules that use the same executable and the standard 3D graphic views.
Note: EDG does not form part of the formal definition of PDMS and is subject to change.
There is no AVEVA commitment to keep or maintain this interface in subsequent
versions of PDMS.
3.1 Overview
The EDG interface has been developed using the basic core functionality available in the
Forms and Menus system.
Even though the underlying core commands are very powerful allowing the developer great
flexibility and control of graphical picking, they only relate to a single view gadget, and so
would require the developer to write their own code to encapsulate the commands and
maintain the graphical views the event is to be applied to.
3.2 Purpose
What the EDG system does, is to control the event handlers in a more global sense, so that
the same pick sequence is applied to all current graphical design views.
It also handles the stacking of EDG events, allowing the user to temporary suspend one
event with another, then return to the previous, without the lost of data, etc.
3.3 Scope
The current implementation has been developed mainly for the DESIGN module using the
standard 3D Graphical Design views. The system can be used in any of the modules using
the "des" executable and the standard 3D Graphical Design views, e.g. IsoSpool,
PARAGON, etc. The current implementation it is not available in DRAFT.
Only the interfaces described can be classed as being supported in any form or manner.
3.4 Definitions
The following are abbreviations, acronyms and "buzz words" that may be used within this
document:
• EDG - Event Driven Graphics, this allow the application writer supply their own method
for interpreting the pick from the view gadget.
• Event Handlers - these are core defined handler that are used define the interaction
with the view gadget.
• Geometry Calculator - set of core functions, objects or methods used to derive
positional, angular, linear or directional data.
• GUI - Graphical User Interface, the forms and menus the user interacts with.
• Super Applications - these are applications/utilities, that are used for creating
elements, (sections, panels, etc.) or moving items, etc.
• Sub Applications - these are applications/utilities, used to derived data that may be
required when using the positioning tool kit, measure, construction aids, etc.
• edgCntrl - this is the global control object for the EDG system, the global variable for
the system within PDMS is !!edgCntrl.
• Packet - this is an object that defines a complete definition of an application/utility that
is to be placed into the event system.
• PickPacket - this is a definition of the pick sequence and types that are used by an
application packet.
• PickType - this is a definition of how an actual pick is interpreted, e.g. if a database
element is picked, is it decomposed into a basic graphical entity, point, line, arc or
plane or is it returned as a pointer to the database element.
• Pick - this is the definition of the pick on the graphical canvas, it is a stylised version of
the core event handlers.
• Public Members & Methods - these are the members and the methods that the
AppWare developer should use when defining objects within the system.
return the picked element and pick vector. Bring the PML language up to date with other OO
languages and GUI tool kits.
However, the old suspend macro command are still available, but should not be used for
any new development, as it is intended to deprecate these commands at some later version.
3.7 Components
There are several components that the EDG system uses; each component of the system
usually has an equivalent object definition. Its members and methods, defining the data
required and actions that are pertinent to that component.
Several of components within the system can be loosely defined as being a type of object
factory; these allow new components to be added into the system, without the need to
modify the base EDG system objects.
There are two main types of components that the system uses, these are:
Object Description
edgCntrl Controls and contains all currently active events that are
registered in the system.
edgPacket Defines a application/utility that requires graphical picks.
edgPickPacket Defines the pick sequences and types of pick a packet
requires.
edgPickType Defines how a pick is to be interpreted.
edgPick Defines the basic graphic pick, cursor style, filter, etc.
edgPosCntrl Object for controlling all graphical position picks settings and
active working planes/grids.
There are several other components that the system uses. However, these are to be
classed as being private to the EDG system, therefore the AppWare developer should never
access the directory.
The following table lists the secondary components and object that are used by the system:
Object Description
edgTypes Object factory for defined "edg" database type object, the
interpreting how a database element is decomposed into
their basic geometrical type, point, line, arc or plane.
appMathLib Object factory for graphical application mathematical objects,
used to derive information about basic geometrical objects,
i.e. proportion, distance, etc.
edgPickData Return data from a graphical pick.
edgPositionData A processed version of the edgPickData object that is used
to extract position and basic geometrical data from a picked
element.
The system access many more components, either directly or indirectly, the above shows
only those that are extensively used in the interpretation of data.
3.8 Concepts
There are several concepts that need to be understood by the AppWare developer, to
understand why the system is written the way it has and how best to use the system.
3.8.2 Picking
Previous to the implementation of the EDG functionality, picking within the graphics view
had a limited scope, in that it was a means to navigate to an element in the database or a
way of identifying and returning some key features on an item in the graphics, i.e. ppoints or
plines.
What EDG allows now is a richer set of functions that allow the user to specify the type of
pick the user can perform, which can have predefined criteria applied to them and richer set
of return information that the user can use without having to derive the information within
their own application code.
Adding/Removing Events
Methods for adding and removing event packets to and from the event system:
All members and methods NOT defined within the table should be classed as being private
to the control object. Therefore, AppWare developer should never use them when writing
applications.
Any code in the macro, function or method which is after the event has been added into the
system, will be completed before the event is available to the user.
Note: Code after the .add method, SHOULD NOT modify any element of the packet
definition, i.e. forms, global variable, etc. as it will only modify the local definition, not
the one that has been added on the EDG system.
Note: Where there is a form associated with an event packet, the form will automatically be
removed by the event system, when the packet is removed from the system.
-- Initialise Data
!this.cache.clear()
endif
Note: Several of the predefined event packets, maintain the prompts in a more direct
manner, these mechanisms MUST NOT be copied by the developer, as they are
maintained by the standard product and could potentially change without notification.
A third method of the event system, allows a stacked events primary prompt to be changed.
This will mean that when the event is reinstated as the active event, the prompt will be
different, than when it was added to the stack.
This is basically the same as the setting of the primary prompt of the currently active event,
but changes the event by description. This is regardless of whether the event is active or
stacked.
!!edgCntrl.viewStack()
Pick Packet
Description : Standard Distance Measure
Pick Packet
Description : Standard Element Pick
Administration Data
There are several administration members available within the event object.
Currently the only members that have any relevance and are used by the system are:
All packets relating to the same utility should have the same
description. This makes the removing and maintenance of the
system a lot simpler.
.priority Defines the priority within in the edg system of the packet, with
respects to other packets of the same description.
The priority is a real number, zero being the highest priority. Where
a primary packet (priority = 0) is added to the system and there is
already another primary packet in the system. The user will be
prompted to whether they want to replace the one currently in the
system with the one being added.
Note: Only packets of the same priority are removed from the
system, lower priorities DO NOT get removed when a higher
one is added.
.form Contains a pointer to the form that is to be shown when the event is
added into the system.
As the member is of "form" data type, the form MUST exist before it
is assigned.
When the event packet is added to the system, the form will
automatically be shown and any initialisation for the form will be run
as normal. The form will be shown at the right hand side of the
screen, slightly offset from the top. This allows any low level
controlling forms (especially the positioning control form) to be
positioned above the form.
When the event packet is removed from the system, the form will
automatically be removed from the system and any low level control
forms that the packet may require.
When another event is placed on the stack, the form will still be
active, however, the event picks will relate to the event packet at the
top of the stack. Any low-level forms that are not required by the
new event packet, will be left on the screen, but made inactive. This
shows that they are still required be a currently stacked event, but
does not allow the modification of the event packet until the event
has been reinstated at the top of the stack.
Actions
All actions within the event packet object are defined as strings, however, they MUST
represent either a standard command, PML function or PML object/form method. Old style
macros MUST NOT be used within the actions of the object.
The main actions that a packet can have are:
.initialisation The action that is carried out when the event packet is initially
added to the edg system.
.action An action which is carried out when all the picks within the pick
sequence object (edgPickPacket) have been successfully
completed.
All data derived from picking in the sequence object are returned
through the system via the local variable !this.return (refer to
Output Data).
.close An action which is carried out just prior to the event packet being
removed from the edg system, whether after a successful
completion of the .action, forcibly by another action of the same
priority/type or using the escape key, when in the graphics canvas.
The action is carried out within the event packet object, therefore,
arguments that refer to !this relate to the members of the event
packet object itself.
Where a packet has a form associated with the packet (using the
.form member) then the close action should not attempt to hide the
form, as the system will automatically remove the form.
.continue An action which is carried out after the event packet has been
removed from the edg system, whether after a successful
completion of the .action or forcibly by another action of the same
priority.
Pick Definition
The Pick Definition defines the number and types of picks required for the event packet
(refer to Pick Packet (edgPickPacket).
There are several predefined methods that allow the most commonly used event pick
sequences to be declared without the need to define them explicitly. Where a predefined
pick sequence does not exactly give the required picks, they can be used as a basis, then
modified to suite the requirements.
Where there is no event packet method defined that gives the required pick sequences and
pick types, then the developer will have to define the pick packet from first principles.
However, it is hoped that the currently available methods for defining the pick sequences
are adequate for most.
See below for a full list of the available methods (refer to Pick Sequence Methods).
Input Data
Where data is to be passed to an event packet, that is used either on initialisation or whilst it
is running, the data has to be stored in the objects .input member. This means the event
packet can run autonomously without the need to access data from external variables or
forms.
The input member is an ARRAY type, allowing any variable data type to be passed to the
system. Setting the input data is the same as defining any other array element:
When using the input data, the developer MUST make sure that they know the positions
and data type of the element of the array they are using.
As input member can only be accessed directly from within the system by the action
routines associated with the action members of the event object. The input variable must be
refereed to thus !this.input:
Note: Variables are passed by reference, therefore, changing the variable associated to the
input variable, will change the input variable.
Where a pick sequence requires multiple picked and the lower objects do not process the
pick data, then the return array will contain multiple entries, one for each pick.
Output Data
All the objects within the event picking mechanism have a .return members, this is used to
pass the data between the objects within the system. All the objects are of an ARRAY type,
as this allows any data type to be assigned to the elements.
When a pick sequence has completed, all the derived data ascertained from the picking, will
be returned into the .return member of the pick event object. Therefore, all .action routines
requiring the pick data MUST use the variable.
Similar to the input variable, the return variable can only be accessed directly from within the
system, and therefore must be declared in the argument list of the actions as !this.return.
-- Action routine
_!packet.action = '!!form.eventAction(!this.return)
In most instances, only the first element of the return array will be populated. This could be
either with another array or a specific object type. In these cases, the developer may want
only to pass the relevant element to the action routine:
-- Action routine
_!packet.action = '!!form.eventAction(!this.return[1])
Note: Variables are passed by reference, therefore, changing the variable associated to the
return variable, will change the input variable.
Members
These are the published members for the object that the developer can used to define the
event packet object:
Name Action
.navigate() Standard navigate pick.
.elementPick(<prompt>) Standard database element pick.
.plinePick(<prompt>) Standard pline pick.
.anyPick(<prompt>) Standard "any" pick.
.aidPick(<prompt>) Standard graphical aid pick.
The following are the standard available pick sequence methods and the event packet
settings that can be modified by the developer. Members not shown in the list, but which are
available for the developer, should be left as defined by the method, so that the pick
sequence works correctly:
fixedRadius3D Defines an arc centred on the first position pick, where the
second and third positional pick defines the X and Y axes
respectively. Radius is specified via the automatically
displays input form.
fixedDiameter3D Defines an arc centred on the first position pick, where the
second and third positional pick defines the X and Y axes
respectively. Diameter is specified via the automatically
displays input form.
diameter2D Derives an arc lying on the active working plane, where the
diameter and X axes is through the two positional picks.
radius2D Derives an arc lying on the active working plane, centred
about the first positional pick, the second positional pick
defines the radius and X-axes.
fixedRadius2D Defines an arc lying on the active working plane, centred
about the positional pick. Radius is specified via the
automatically displays input form.
fixedDiameter2D Defines an arc lying on the active working plane, centred
about the positional pick. Diameter is specified via the
automatically displays input form.
fillet Defines an arc of radius specified via the automatically
displays input form, that lies tangentially to the two picked
lines.
tanTan Defines an arc of radius specified via the automatically
displays input form, that is tangential to the two picked arc
elements. The third pick (positional) define the centre side of
the arc.
pntTan Defines an arc centred on the first pick (positional) which is
tangential to the second pick (curved element).
fixedRadiusPntTan Defines an arc with radius supplied by the automatically
displayed input form, which lies on the line between the first
pick (positional) and the picked curved element.
fixedRadiusPntPnt Defines an arc centred on the first positional pick which is
tangential to the second pick on a curved element.
derive Derives an arc from the picked element.
tan3Lines Derives an arc which fits between the three lines picked.
Packet Members Settings
.description Defined by option.
.priority 0.
.remove True.
.input
Return Array Description
[1] arc Standard arc object.
lineAngle Defines a real that relates to the angle between the two
linear items picked.
Packet Members Settings
.description Defined by option.
.priority 0.
.remove True.
.input
Return Array Description
[1] line (distance) Standard line object.
[1] line (shortest) Standard line object.
[1] arc (angle) Standard arc object (radius is unit length of 1000mm).
[1] real (lineAngle) Real.
Note: When defining event packets using the above methods, the method should be
applied to the object before any other member is set, as the methods will overwrite
several of the event packet members.
3.10.2 Examples
The following are several examples and descriptions for setting up some basic packets
using the standard pick sequence methods.
-- Remember the element when the packet was first place in the
-- event system
!packet.initialisation = '!this.input[1] = !!ce'
-- Set the close sequence, so that the user returns to the original
-- element
!packet.close = '!!ce = !this.input[1]
Again, this packet does not use other objects, functions or forms in its running. However, it
could be adapted to use objects, functions or forms when running. This could allow the
elements picked twice to be removed from the list, then some special action carried out on
all elements selected on the close of the packet.
The following is an example of a packet definition that will run functions that store the picked
element (in a global variable), then on completion, enhance all the elements selected.
When the event is placed into the event system, it will automatically initialise the global
variable that is used to store the picked elements:
The following is the function definition that stores the picked element in a global variable,
enhancing the picked element. If the same element is picked twice, then it will be removed
from the list and un-enhance it:
-- Function Definition
define function !!xxxStoreElement(!element is DBREF)
-- End of definition
endfunction
The following functions definition is used to tag "MARK" all the elements that are in the
global variable:
-- Function Definition
define function !!xxxTagElements()
-- Tag Item
MARK $!!<xxxGlobalStore[$!<i>]>
-- Unenhance element
UNENHANCE $!!<xxxGlobalStore[$!<i>]>
enddo
-- End of definition
endfunction
-- Associate form
!packet.form = !!xxxForm
It should be noted that there are several ways in which the event packet form can be closed:
• Form gadget, OK/Cancel/Dismiss button or Close on pull-down
• Close from the forms pull-down, top-left-hand corner of the form
• Using the <esc> key when in a design graphics canvas
When closing the event from the from (one of the first two methods) then the event packet
MUST be removed using the event systems .remove method, supplying the same
description that event packet was placed onto the system with:
!!edgCntrl.remove(<event packet description>)
When using the <esc> in the design canvas, then only the relevant tidy-up sequence of the
form should to be used. The developer MUST NOT use a method that has the event
systems .remove method in, this could cause problems.
The following example equates to the old style "pick a pline of a section":
The following example equates to the old style "pick a ppoint of an element":
Notes:
1. With the EDG system, it is not possible to instigate an event and suspend the currently
active macro then return to the same point in the macro, once the pick is completed. If
the developer wants to simulate the suspension of a macro, i.e. wait for the pick on the
graphics canvas. Then, the invocation of the event packet MUST be the last command
within the file and the action to be carried out after the pick, MUST be in the function/
method defined in the .action member.
Command defined after the invocation of an event packet within the same macro,
MUST NOT rely on the pick data of the event. Also it should be noted that any changes
to the packet definition WILL NOT have any effect on the event packet that has been
added to the system.
2. All of the above will automatically use the standard filters set via the filter utility within
the application. If an event packet is required that has a specific type of pick filter and
the standard filters are to be ignored, see below.
stack the packet that is running, only removing it from the system, once the subsequent
packet has finished.
Administration Data
Unlike the administrative members of the event object, these members of this object are
only for interrogation by the developer and do not perform or define any characteristics of
the pick packet, they are only for information.
Actions
There is only one action member of the pick packet object .action this defines the action
that is carried out once all the picks within the pick packet definition have been completed.
Where a developer wish to define an action that is triggered on the completion of all picks,
then refer to the event packet action section, as the same principles apply to the definition of
the pick packet action.
In most instances the predefined methods within the object can be used via a method on the
event packet object edgPacket (refer to Pick Sequence Methods). Therefore, in most cases
the use of the pick packet predefined methods should not be required.
Input Data
The input data mechanism is identical to that of the event packet input mechanism, i.e. if
data is to be passed about within the pick packet definition, then it should be via the .input
array (refer to Input Data).
Even though the input member has been included in the system, it currently has not been
used within any of the EDG developed so far. Therefore, even though the mechanism is
available it has not been extensively tested.
Output Data
The output data mechanism is identical to that of the event packet object (refer to Output
Data).
Members
The following are published member interface into the object, members not defined within
this table are internal to the object and should never be set by the developer.
Methods
There are several methods that can be used to define a standard pick packet, the following
are the ones currently supported:
Name Action
.stdGphWindow(<prompt>) Standard graphical window pick (only screen position
used).
.stdScreen(<prompt>) Standard screen pick.
.stdView(<prompt>) Standard screen pick.
Note: Where pick packet definitions are supplied with arguments with a specific data type,
then these values have to be supplied before the event packet is placed in the event
system. However, where pick packets have an <any> argument type, the can be
supplied as a pointer (expression) that evaluates into the correct data type when the
action of the pick is evaluated.
The following are the standard available methods and their default settings that can be
modified or used by the developer. Members not shown in the list, but which are available
for the developer, should be left as defined by the method.
.key stdElement.
.input
Return Array Description
[1] edgPickData Standard event pick return object.
.key circleFRadPntTan.
.prompt Circle (point - tangent).
.input
Return Array Description
[1] ARC Standard arc object.
.key linePntTan.
.prompt Line (point - tangent).
.input
Return Array Description
[1] LINE Standard line object.
Note: When defining pick packets using the above methods, the method should be applied
to the object before any of the other members are set, as the methods will overwrite
several of the pick packet members.
Note: The definitions of the event packets that the pick packet is to be applied to are not
shown. See below for how the pick packet can be defined with respect to an event
packet (refer to Examples (Using Pick Packets).
Element-Position Picking
The Element-Position Picking example shows how the developer can define a pick
sequence that firstly asks for an element to be picked, then for a derived position to be
picked.
This type of pick sequence can be used to identify an element, then reposition it in a new
place.
-- Define information
!pickPacket.key = 'element-position'
!pickPacket.description = 'Pick an element then a positions'
Note: No action is carried out within the pick packet, therefore, all the data will be returned
from each of the pick and will be passed back up the event system to the event
packet unmodified.
Note: If the pointer to the gadget was unquoted, i.e. passed as a REAL value. The current
value of the form gadget would be used and changing the value on the form would
have no effect when the pick packet action is executed.
Whereas, passing the pointer to the form gadget as a string, take the string and
evaluate it at the action time.
-- Set Members
!packet.description = 'Test Packet'
!packet.key = 'testPacket'
!packet.priority =1
The pick packet definition can be either done using a standard method on the object (as
above) or defined fully, where there is no standard method.
Method Definition
The Method Definition example is where an object/form has a method(s) that defines a pick
packet sequence that can be applied to a standard event packet within the object/form.
The following is the definition of the method that defines the pick packet:
Method Definition
-- Define Method
define method .elementMove() is EDGPICKPACKET
-- Define information
!pickPacket.key = 'element-position'
!pickPacket.description = 'Pick an element then a positions'
-- Return
return !pickPacket
The following is an extract on how the above method would be used within the owning
object/form:
-- Define Packet
!packet = object EDGPACKET()
.
.
.
Position Picking
The following methods are used to define a specific type of filtered pick which returns an
edgPositionData object, the position member of the return object is populated:
Name Action
stdPosition(<prompt>) Standard positioning pick type, derives the position from
the graphical pick (pick type and method are controlled by
the positioning control form).
The initial position derived, will then be mapped against the
active working plane (when set) then the currently defined
offset method will be applied to the position.
positionLinear(<prompt>) Positioning pick for linear elements, converts picked item
into a linear element, then derives the position on the linear
item.
positionArc(<prompt>) Positioning pick for arc elements, converts the picked item
into an arc, then derives the position on the arc.
positionPlane(<prompt>) Positioning pick for plane elements, converts the picked
item into a plane, then derives the position onto the plane.
Name Action
stdElement(<prompt>) Standard element pick type, this will only pick database
element in the graphic views.
By default the standard element filters will be applied to the
pick, only allowing those elements that conform to the define
rule for the filter.
stdAny(<prompt>) Standard any pick type, this will allow elements, plines,
ppoints and graphical aids to be in the graphic views.
By default all the standard filters will be applied to the pick.
stdPpoint(<prompt>) Standard element pick type, this will only allow elements
containing ppoints or design points to be picked in the
graphic views.
By default the standard ppoint filters will be applied to the
pick.
stdPline(<prompt>) Standard element pline type, this will allow only elements that
have plines to be picked from in the graphic views.
By default the standard pline rules will be applied.
stdAid(<prompt>) Standard Aid element pick type, this will allow all graphical
aids to be picked from the graphical views. However, graphic
aids not registered within the "Construction Aid" utility will
return an error.
stdScreen(<prompt>) Standard screen pick, this will allow a pick anywhere within
the graphical view to be performed. This can considered as a
2D pick within the 3D view.
stdGraphics(<prompt>) Standard graphics pick, this will allow any graphical entity to
be picked within the graphics view, i.e. database element,
graphical aid, ppoint or pline. All elements, will be
decomposed into one of three basic types:
vertex single point at the convergence of edges
edge boundary between facets
facet planar surface of an item
Name Action
dbLine(STRING) Setup for picking a linear db item, this will always try and
convert the picked database element into a line. The method
will try and populate the .line member of the return object.
dbCircle(STRING) Setup for picking a circular db item, this will always try and
convert the picked database element into an arc. The
method will try and populate the .arc member of the return
object.
dbPlane(STRING) Setup for picking a plane db item, this will always try and
convert the picked database element into a plane. The
method will try and populate the .plane member of the return
object.
Miscellaneous
The following methods are used to define a specific type of filtered pick which returns an
edgPositionData object, however, the position member of the return object is NOT
populated:
Name Action
stdView(STRING) Standard view pick, this returns the view gadget the pick is
performed in.
3.12.2 Examples
As there is not member that should be defined by the developer, the example for the
definition of pick packets will suffice as on how to use the pick type methods. Refer to
Examples (Defining Pick Sequences).
.input This is an array member, containing the qualifiers used to define the
filtering when picking from the graphics view. Each element of the
array relate to a specific type of item, which can be picked, these
are:
[3] Element, filter applied to only allow elements that conform to the
defined rule to be picked.
[4] Design Aid, filter applied to only allow design aids that conform
to the defined rule to be picked.
[6] Graphical Entity, allow only the graphical entities defined in the
member to be pick, these are, VERTEX, EDGE or FACET. If no
entry is defined, then all graphical entities are pickable.
Note: The filtering rules are evaluated as the cursor passed the
item in the graphic view.
Rules for design elements and tubing are evaluated on only the
design element that can be picked, primitive, piping component,
SCTN, etc. Whereas the rules for ppoints and plines are evaluated
at the point of definition, i.e. on the catalogue definition of them, this
means that information pertaining to the ppoint or pline when in the
design space CAN NOT BE USED.
Element rules are always evaluated before the ppoint and pline
rules, therefore, if an element rule excludes anything that has a
pline, e.g. TYPE eq 'BOX', then the user will not be able to select a
element to pick.
.modifiable If this member is set to true this applies the standard filter to the pick
when the pick becomes active. When false, the currently defined
local rules within the .input member are used.
Note: If you have defined some input rule, this member MUST BE
set to false, otherwise the rules defined within the standard
filtering utility will over-ride the settings when the pick
becomes active.
Even though some combination of rules are permissible, the actual usefulness of the
combination is limited.
Note: Dependent on the underlying pick method used, some of the rules will have no effect,
e.g. setting a graphic pick filter when using the pick elements handler, has not
meaning.
3.13.4 Examples
The following are examples show how to set the pick filter, the first example shows how the
filter is set from the event packet level. All subsequent examples show what filter rules that
can be applied.
-- Define Rule
!rule = 'TYPE of OWNER inset (|EQUI|,|SUBE|)'
-- Set the pick filter for element to only equip and subequip
!packet.pickPacket.picks[1].pick.input[3] = !rule
Note: As only certain element types can be actually picked from the graphic canvases, e.g.
primitives, tubing, etc. Then the rule MUST in this case check whether the parent of
the element is either an equipment or sub-equipment.
-- Set the pick filter for element to only equip and subequip
!packet.pickPacket.picks[1].pick.input[1] = !pline
!packet.pickPacket.picks[1].pick.input[3] = !element
Note: The pline rule relates to the attribute that is on the catalogue definition of the section
profile.
Method
The pick data object only has one method, this returns the pick data object as a picked
position object.
Members
The following are the definition of the members:
Methods
There are several methods avail these are:
A PML 1 Expressions
This appendix explains the PML 1 expressions package. These facilities are needed within
AVEVA products, for example, to define report templates in PDMS.
Expressions have types. For example, you can have numeric expressions, text expressions
and logical expressions. All the elements in an expression must be of the correct type. For
example, if you have a two numbers, x and y, and two text strings text1 and text2, the
following expression is meaningless:
x + text1 $
Expression
Logical Expressions
Logical Array Expressions
Numeric (Real) Expressions
Real Arrays
Text Expressions
‘This is text’
There must be a space between each operator and operand. For example:
x + y
Use round brackets to control the order of evaluation of expressions and to enclose the
argument of a function. For example:
SIN(30)
In general, you do not need spaces before or after brackets, except when a name is
followed by a bracket. If there is no space, the bracket will be read as part of the name. For
example:
(NAME EQ /VESS1 )
Operator Comments
BRACKETS Brackets can be used to control the order in which
operators are evaluated, in the same way as in
normal arithmetic
FUNCTIONS
*/
+-
EQ, NEQ, LT, LE, GE, GT
NOT
AND
OR
( (SIN(!angleA) * 2) / SIN(!angleB) )
• Logical operators.
• Logical functions.
Operator Comments
AND
EQ, NE The operators EQ and NE may be applied to any pair
of values of the same type.
GT, GE, LE, LT The operators GE, LE, GT and LT may only be used
with numbers and positions. Refer to Positions,
Directions and Orientations in Expressions (PDMS
only) for more information.
NOT
OR
Note: The operators EQ, NE, LT, GT, LE and GE are sometimes referred to as comparator
or relational operators; NOT, AND and OR are sometimes referred to as Boolean
operators. Refer to Precision of Comparisons for tolerances in comparing numbers.
AND
Description Perform the logical AND between two logical values. Treats
unset values as FALSE.
Side Effects If one of the values is undefined and the other one is FALSE,
the result is FALSE.
EQ and NE
NOT
OR
Side Effects If one of the values is undefined and the other one is TRUE,
the result is TRUE.
Function Comments
BADREF
DEFINED,UNDEFINED
CREATED
DELETED
EMPTY
MATCHWILD
MODIFIED
UNSET
VLOGICAL
BADREF
CREATED
DELETED
EMPTY
MATCHWILD
MODIFIED
Synopsis
.-----------------------------------.
/ |
>- MODIFIED-(-+- attname -------*- DESCENDANTS --+-+-comma +-attname -’
| | | |
|- DESCENDANTS -. |- SIGNIFICANT --| |
| | | | |
|- SIGNIFICANT--| |- PRIMARY ----- | |
| | | | |
|- PRIMARY -----| |- OFFSPRING-----| |
| | | | |
|- OFFSPRING ---| ‘----------------’ |
| | |
| | |
| | |
‘---------------+--------------------+--+-- ) - OF - id
|
‘-
The MODIFIED, DELETED and CREATED functions are not implemented within PML2
expressions.
UNSET
VLOGICAL
VLOGICAL is used for the late evaluation of variables.
Side Effects If the scalar variable, the array variable, or the array variable
element does not exist, the result is undefined.
Operator Comments
+ Addition.
- Subtraction.
* Multiplication.
/ Division.
Side Effects Units are consolidated across Multiply and Divide. The
dimension of the result of the expression is determined from
the combination of all the values being combined. For
example 1kg / (1m * 1m *1m ) will give a density of 1kg/m3.
Function Comments
ABS ( number1 ) Gives the absolute value of a number
ACOS ( number1 ) Gives the arc cosine of a number, in degrees.
ASIN ( number1 ) Gives the arc sine of a number, in degrees.
ATAN ( number1 ) Gives the arc tangent of a number, in degrees.
ATANT ( number1, number2 ) Gives the arc tangent of number1/number2, in
degrees, with the appropriate sign.
ALOG ( number1 ) Gives the exponential function (natural anti-log)
of a number.
ARRAY(pos or dir or ori) Converts a position, direction or orientation
value or attribute into three numbers.
ARRAYSIZE ( variable-name Gives the size of an array variable.
)
ARRAYWIDTH( variable-name Gives the largest display width of any string in
) array variable-name.
COMPONENT dir OF pos2 Gives the magnitude of a vector drawn from E0
N0 U0 to pos2, projected in the direction dir1.
INT ( number1 ) Gives the truncated integer value of a number.
SIN ( number1 ) Gives the sine, cosine or tangent value of a
number (considered to be in degrees).
COS ( number1 ) Gives the sine, cosine or tangent value of a
number (considered to be in degrees).
TAN ( number1 ) Gives the sine, cosine or tangent value of a
number (considered to be in degrees).
LENGTH ( text1 ) Gives the length of text1.
LOG ( number1 ) Gives the natural logarithm of a number.
MATCH ( text1, text2 ) Gives the position of the beginning of the
leftmost occurrence of text2 in text1. If text2
does not occur in text1, 0 is returned.
Function Comments
MAX ( number1, number2[ , Gives the maximum value of the arguments.
number3 [. . .]]) )
MIN ( number1, number2[ , Gives the minimum value of the arguments.
number3 [. . .]]) )
NEGATE Multiply a number by -1.0.
NINT ( number1 ) Gives the nearest integer to a real. NINT(N+0.5)
is equal to N+1 if N is positive or equal to zero,
to N if N is negative.
OCCUR ( text1, text2 ) Gives the number of times string text2 occurs in
string text1.
REAL ( text1 ) Try to read a number at the beginning of text1.
POWER ( number1, number2 ) Gives the value of number1 raised to the power
number2.
SQRT ( number1 ) Gives the square root of a number.
VVALUE ( variable-name ) Used for late evaluation of variables. Gives a
real value.
ABS
ALOG
ARRAY
ARRAYSIZE
Side Effects If the array variable does not exist, the result is undefined.
ARRAYWIDTH
INT
LENGTH
ALOG
MATCH
NEGATE
NINT
OCCUR
Description Counts the number of times string text2 occurs in string text1
REAL
POWER
Side Effects Units are consolidated across POWER. The dimension of the
result of the function is determined from the input quantities.
SQRT
Side Effects Units are consolidated across SQRT. The dimension of the
result of the function is determined from the input quantities.
VVALUE
REAL(string) and VVAL(!stringvar) functions:
These will return the value of the number in the string IGNORING any unit qualifier.
The unit qualifier must still be a valid unit qualifier. This is done so that output from $! and
VAR ! combinations of commands can still be accepted by the REAL function and other
functions with or without unit qualifiers appended
VVALUE is used for the late evaluation of variables.
Side Effects If the scalar variable, the array variable or the array variable
element does not exist, the result is undefined.
answer is required relative to the owner axis system and this is taken as the default. For
example:
If we require the result in some other axis system then the WRT keyword is used. For
example:
The default is that Cartesian coordinates are in the owning element’s axis system. This
absolute position can be expressed in different coordinate systems: the default is again the
owner’s axis system.
Note: The CONSTRUCT syntax uses the world as the default axis
Example
Item Comments
A SITE at (0,0,0) With default (World) orientation
A ZONE at (100,0,0) With default (World) orientation
An EQUIPMENT at (100,0,0) With orientation ’N IS E
A BOX at (-100,0,0) With default (World) orientation
The result of Q (N 100 WRT /BOX1), shown as ⊗ in , will depend on the current element.
Location Result
World (300,100,0), in World coordinates.
Site (300,100,0) in World coordinates because the World
is the owner of the current element.
Zone (300,100,0) in World coordinates, because the Site is
the owner of the current element, and the Site
coordinates are the same as the World coordinates.
Equipment (200,100,0), which is the position relative to its
owner, the Zone.
Box (100,100,0) which is the position relative to its owner,
the Equipment.
A.5.3 FROM
In some cases we require an offset from a fixed point, other than the position of an item. For
example, a point or attribute.
The FROM syntax is used for this. We may still use WRT in combination with FROM, but in
this case the WRT is only used to determine the axis direction and not the offset, since the
offset is specified by the FROM part.
Item Comments
A SITE at (0,0,0) With default (World) orientation
A ZONE at (100,0,0) With default (World) orientation
An EQUIPMENT at (100,0,0) With orientation ’N IS E
A BOX at (-100,0,0) With default (World) orientation
The result of Q (N 100 WRT /* FROM /BOX1), shown as ⊗ in , will depend on the
current element.
Location Result
World, Site, and Zone (200,200,0) since the offset of N100 is applied in
world axis rather than /BOX1 axis.
Equipment (100,200,0).
Location Result
Site and Zone (100,0,0)
Equipment (0,0,0)
Box (0, -100, 0), because the axis for the result is the
Equipment.
Location Result
Site and Zone (0,100,0)
Equipment (-100,100,0), because the default result axis is the
Zone.
Box (0, -100, 0), because the axis for the result is the
Equipment.
For positions entered by the user, only those coordinates which are given by the user are
defined. For example:
For the EQ operator, all the pairs of defined coordinates should be equal. For NE, only one
pair of defined coordinates need be different. For GT (LT,GE,LE), all the defined coordinates
of the first position should be greater than (less than, greater than or equal to, less than or
equal to) the defined coordinates of the second position. This means that GE is not the
opposite of LT and LE is not the opposite of GT.
If no coordinate of the two positions are defined for a common axis (e.g. ’N10’ and ’W4D7’),
the result of the comparison is undefined.
Examples
A.5.5 POLAR
The POLAR keyword allows positions to be defined in terms of a distance in a particular
direction from a point.
A.5.6 Direction
The basic ways of defining a direction are:
• Direction attribute plus optional WRT. For example,
HDIR OF /PIPE1 WRT /*
• Cartesian direction. For example,
N 45 W
• Cartesian direction WRT to an element.
• All Cartesian directions are returned in the axis of the owner of the current element. For
example:
(U WRT CE )
• will return the Z axis of the current element relative to its owner.
Q ( Z WRT /SCTN )
• will return the Z axis direction of /SCTN relative to the owner of the current element. For
example, if the result is required in world coordinates the current element must be the
World or a Site.
• FROM pos2 TO pos2. For example
FROM N 50 WRT CE TO N 100
• Keyword AXES followed by a p-point or pline.
• The CLOSEST keyword, which will find the closest element in a particular direction.
The syntax is:
A.5.7 Orientations
The basic ways of defining an orientation are:
• Orientation attribute plus optional WRT. For example:
ORI OF /BOX1 WRT /*
• Cartesian orientation. For example:
dir IS dir AND dir IS dir
• For example to set an orientation of an element to that of a section, rotated by 90
degrees use:
(E IS U WRT /SCTN1 AND N IS E WRT /SCTN1)
• The AXES keyword, which will allow you to use P-points to specify orientations.
.----<--------.
/ |
>-- AXES --*--- PArrive ---|
| |
|--- PLeave ----|
| |
|--- PTail -----|
| |
|--- HHead -----|
| |
|--- HTail -----|
| |
‘--- PPOINT n --+-- OF - <gid> ---->
• An example is:
( AXES PLEAVE IS AXES PLEAVE OF PREV AND AXES P3 IS UP )
• This will orient a branch component, such as a valve, so that it is aligned with the
previous component and its P3 is up.
See also Comparing Positions.
Function Comments
AFTER
BEFORE
DISTANCE
LOWCASE, UPCASE
PART
REPLACE
STRING
SUBS, DSUBS
TRIM
VTEXT
AFTER
BEFORE
DISTANCE
PDMS
For both US and PDMS formats the following rules are
observed:
• If distance is negative, the first symbol is a minus sign.
• If feet is true and the distance is at least a foot, then the
number of feet is output next, followed by a single quote
(’). Only if zeros is true will the number of feet be output
as 0 for distances less than a foot. Otherwise the feet will
be omitted.
• If feet have been output, the inches will be at least two
characters wide. Numbers less than ten will be preceded
by a space if US format is being used or a zero if PDMS
format is used. A zero will be output if there are no whole
inches.
• If no feet have been output and the distance is at least an
inch, then the number of inches is displayed but without
any preceding spaces. Only if zeros is true will a 0 be
output for distances of less than an inch.
• If inches have been output and fraction is true, these will
be followed by a decimal point (.).
Distance Feet & Inch Feet & Inch Inches Inches Feet & Inch
US US US US PDMS
Fraction Fraction Decimal Fraction Fraction
Denom 100 Denom 32 DP 1 Denom 2
Zeros No Zeros Zeros Denom 4 Zeros
No Zeros
PART
REPLACE
STRING
Errors
SUBSTRING
TRIM
VTEXT
VTEXT is used for the late evaluation of variables.
Side Effects If the scalar variable, the array variable or the array variable
element does not exist, the result is undefined.
Setting Comments
NONE No units. e.g. attribute OBS.
UNKN Unknown units. e.g. 10.
MM Dist/bore attribute if units are MM, or literal e.g. 10 mm.
INCH Dist/bore attribute if units are INCH/FINCH, or literal e.g. 10’.
SQIN Multiply two INCH values together, or literal e.g. 10 sq in.
CUIN Multiply SQIN by INCH, or literal e.g. 10 cu in.
On comparison, addition or subtraction of two values the following assumptions are made. If
one of the units is unknown and the other is anything other than UNKN, then the unknown
value is assumed to have the same units as the known units. A suitable conversion is then
done if the known units is INCH or SQIN or CUIN.
For example:
(XLEN GT 10).
If we are working in distance units of inches, it is known that XLEN is a distance value.
Internally the value is held in mm, but the units are held as INCH. The units for ’10’ are held
as unknown. On doing the comparison, the ’10’ is assumed to be inches and thus multiplied
by 25.4 to ensure that the comparison works as expected.
Special action is also taken to preserve the correct units across multiplication, division,
POWER and SQRT, in particular the maintenance of SQIN and CUIN. In these situations,
units of %UNKN are treated as none. For example, (10 * XLEN) is assumed to result in
INCH rather than SQIN. An exception is made when a reciprocal would result from division.
For example: for (10 / XLEN) we assume that the 10 is in inches rather than none.
Object Tolerance
Number Tolerance factor of 0.000001.
In other words, if the difference between two reals is not
greater than 0.000001* (maximum of the two values) then
the values are considered to be equal. e.g.
• (1.000001 GT 1) is FALSE as it considers 1.000001;
and 1 to be equal;
• (1.000002 GT 1) is TRUE.
Position Considered to be equal if within 0.5 mm of one another.
Direction or Orientation Considered to be equal if values are within 0.005.
• An element is undefined (e.g. ’OWNER’ when the current element is the WORLD).
• An attribute is unset (e.g. text attribute or UDA of length 0).
• A variable is undefined (e.g. ’VVAL(!ARC6)’ where !ARC6 has never been
initialised).
• Two position constants are compared with GT, GE, LT or LE and they have no common
coordinates (e.g. ’N10 EQ E5’).
• If the result of the whole expression is undefined, an error occurs.
Index
A COSINE . . . . . . . . . . . . . . . . . . . . . . . . A:18
CREATED . . . . . . . . . . . . . . . . . . . . . . . A:7
ABS . . . . . . . . . . . . . . . . . . . . . . . . . . . . A:15
ACOS . . . . . . . . . . . . . . . . . . . . . . . . . . A:15
ADD . . . . . . . . . . . . . . . . . . . . . . . . . . . A:13
D
AFTER . . . . . . . . . . . . . . . . . . . . . . . . . A:32 DEFINED . . . . . . . . . . . . . . . . . . . . . . . . A:7
ALOG . . . . . . . . . . . . . . . . . . . . . A:16, A:18 DELETED . . . . . . . . . . . . . . . . . . . . . . . . A:8
AND . . . . . . . . . . . . . . . . . . . . . . . . . . . . A:3 DISTANCE . . . . . . . . . . . . . . . . . . . . . . A:33
AREA command ( Design and ) . . . . . 2:203 format . . . . . . . . . . . . . . . . . . . . . . . A:33
Area view gadget . . . . . . . . . . . . . . . . 2:203 US format . . . . . . . . . . . . . . . . . . . . A:33
Area view setup mode . . . . . . . . . . . . 2:203 DIVIDE . . . . . . . . . . . . . . . . . . . . . . . . . A:13
ARRAY . . . . . . . . . . . . . . . . . . . . . . . . . A:16
ARRAYSIZE . . . . . . . . . . . . . . . . . . . . . A:16
E
ARRAYWIDTH . . . . . . . . . . . . . . . . . . . A:17
ASIN . . . . . . . . . . . . . . . . . . . . . . . . . . . A:15 EMPTY . . . . . . . . . . . . . . . . . . . . . . . . . . A:8
ATAN . . . . . . . . . . . . . . . . . . . . . . . . . . A:15 EQUAL . . . . . . . . . . . . . . . . . . . . . . . . . . A:4
ATANT . . . . . . . . . . . . . . . . . . . . . . . . . A:15 Event
Attributes Control System . . . . . . . . . . . . . . . . 3:6
in expressions . . . . . . . . . . . . . . . . A:41 Flow . . . . . . . . . . . . . . . . . . . . . . . . . 3:5
Packet . . . . . . . . . . . . . . . . . . . . . . . 3:5
B Event Driven Graphics . . . . . . . . . . . . . . 3:1
Event Packet . . . . . . . . . . . . . . . . . . . . 3:11
BADREF . . . . . . . . . . . . . . . . . . . . . . . . . A:6 Example
BEFORE . . . . . . . . . . . . . . . . . . . . . . . . A:32 Defining Pick Sequences . . . . . . . . 3:52
Boolean operators . . . . . . . . . . . . . . . . . . A:3 Repeat Element Pick . . . . . . . . . . . 3:24
Single Element Pick . . . . . . . . . . . . 3:23
C Using Pick Packets . . . . . . . . . . . . 3:54
Expressions
COLUMNFORMAT . . . . . . . . . . . . . . . . 2:36 directions in . . . . . . . . .A:28, A:29, A:31
Comparator operators . . . . . . . . . . . . . . . A:3 format . . . . . . . . . . . . . . . . . . . . A:1, A:2
Comparison precision IDS in . . . . . . . . . . . . . . . . . . . . . . . A:22
in expressions . . . . . . . . . . . . . . . . A:42 logical . . . . . . . . . . . . . . . . . . . . . . . . A:2
Components . . . . . . . . . . . . . . . . . . . . . . 3:3 logical array . . . . . . . . . . . . . . . . . . A:11
Main . . . . . . . . . . . . . . . . . . . . . . . . . 3:3 nesting . . . . . . . . . . . . . . . . . . . . . . . A:2
Secondary . . . . . . . . . . . . . . . . . . . . 3:3 numeric . . . . . . . . . . . . . . . . . . . . . A:12
G N
Gadget NEGATE . . . . . . . . . . . . . . . . . . . . . . . A:19
2D Screen Position . . . . . . . . . . . . . 2:10 NEQUAL . . . . . . . . . . . . . . . . . . . . . . . . A:4
Anchoring . . . . . . . . . . . . . . . . . . . . . 2:7 NINT . . . . . . . . . . . . . . . . . . . . . . . . . . . A:20
BAR . . . . . . . . . . . . . . . . . . . . . . . . 2:26 NOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . A:5
BUTTON . . . . . . . . . . . . . . . . . . . . . 2:30 NUMBER (REAL) . . . . . . . . . . . . . . . . . A:20
COMBOBOX . . . . . . . . . . . . . . . . . 2:38 Numeric expressions . . . . . . . . . . . . . . A:12
CONTAINER . . . . . . . . . . . . . . . . . 2:42 Numeric operators . . . . . . . . . . . . . . . . A:13
Docking . . . . . . . . . . . . . . . . . . . . . . 2:7
FRAME . . . . . . . . . . . . . . . . . . . . . . 2:70 O
LINE . . . . . . . . . . . . . . . . . . . . . . . . 2:78
LIST . . . . . . . . . . . . . . . . . . . . . . . . 2:90 OBJECT . . . . . . . . . . . . . . . . . . . . . . . 2:115
OPTION . . . . . . . . . . . . . . . . . . . . 2:116 Object
PARAGRAPH . . . . . . . . . . . . . . . . 2:121 ALERT . . . . . . . . . . . . . . . . . . . . . . 2:11
Positioning . . . . . . . . . . . . . . . . . . . . 2:8 ARC . . . . . . . . . . . . . . . . . . . . . . . . 2:12
RTOGGLE . . . . . . . . . . . . . . . . . . 2:164 ARRAY . . . . . . . . . . . . . . . . . . . . . 2:21
SELECTOR . . . . . . . . . . . . . . . . . 2:171 BANNER . . . . . . . . . . . . . . . . . . . . 2:25
SLIDER . . . . . . . . . . . . . . . . . . . . 2:176 BLOCK . . . . . . . . . . . . . . . . . . . . . . 2:28
Syntax Graphs . . . . . . . . . . . . . . . . . 2:6 BOOLEAN . . . . . . . . . . . . . . . . . . . 2:28
Tagwidth . . . . . . . . . . . . . . . . . . . . . 2:10 BORE . . . . . . . . . . . . . . . . . . . . . . . 2:29
TEXTPANE . . . . . . . . . . . . . . . . . 2:191 Classification . . . . . . . . . . . . . . . . . . 2:1
TOGGLE . . . . . . . . . . . . . . . . . . . 2:193 COLLECTION . . . . . . . . . . . . . . . . 2:34
Width and Height . . . . . . . . . . . . . . . 2:9 COLUMN . . . . . . . . . . . . . . . . . . . . 2:35
GE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A:5 DATEFORMAT . . . . . . . . . . . . . . . 2:43
Graphical Selection . . . . . . . . . . . . . . . . 2:74 DATETIME . . . . . . . . . . . . . . . . . . . 2:44
GT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A:5 DB . . . . . . . . . . . . . . . . . . . . . . . . . 2:46
DBREF . . . . . . . . . . . . . . . . . . . . . . 2:48
I DBSESS . . . . . . . . . . . . . . . . . . . . 2:49
DIRECTION . . . . . . . . . . . . . . . . . . 2:49
IDList . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:76 EXPRESSION . . . . . . . . . . . . . . . . 2:51
IDs in expressions . . . . . . . . . . . . . . . . . A:22 FILE . . . . . . . . . . . . . . . . . . . . . . . . 2:52
INT . . . . . . . . . . . . . . . . . . . . . . . . . . . . A:18 FMSYS . . . . . . . . . . . . . . . . . . . . . 2:54
FORM . . . . . . . . . . . . . . . . . . . . . . 2:57
L FORMAT . . . . . . . . . . . . . . . . . . . . 2:66
LINE . . . . . . . . . . . . . . . . . . . . . . . . 2:79
Late evaluation of expressions . . A:21, A:40 LINEARGRID . . . . . . . . . . . . . . . . . 2:88
Late evaluation of variables . . . . . . . . . A:40 LOCATION . . . . . . . . . . . . . . . . . . 2:95
W
WRT . . . . . . . . . . . . . . . . . . . . . . . . . . . A:23