UNIFACE 8.1.01 - Enhanced UNIFACE Development Environment
The V8 UDE has a new system for filling in default values when creating a new object. In V7, default Proc for Triggers was read from messages in the usys.dol file. In V8, defaults are stored in the Repository as regular definitions under a reserved name. Default values that are used when creating Entities and Fields are kept in an Business Object Model "U". For example, this Model contains an Entity definition "USUPERTYPEDEF" and Field "UFLDDEF.USUPERTYPEDEF".
Defaults for all UNIFACE Component Types are available as Component definitions: For instance there is a Component definition "UFRMDEF", which holds the default values used when creating a new Form, "USVCDEF" is used for Services, etc. These definitions have a single Entity and Field 'painted', which are used when creating new dummy Entities and dummy Fields. All defaults can be edited and modified, using the normal Editors. Changes take effect immediately.
(Note: There are more defaults described in Customizing UNIFACE defaults.)
Loading defaults
On startup, the V8 UDE will check whether all defaults are available in the Repository. If not, you will see the following message:
Important: You must load these defaults, before doing anything else with the V8 UDE. All defaults are imported from an export-file udefaults.trx, which is located in the trx-folder.
The Component Editor in UNIFACE 8 integrates the V7.2 GFP and Trigger Editor into a single Editor with enhanced editing capabilities. It supports specific functionality for Server type Components and Components that have a User Interface. Property Forms for Component (types), Entity and Field Properties are re-grouped.
History Navigation
The Component Editor builds up a history 'stack' of opened Components. This history can be navigated with the 'Forward' and 'Back' buttons in the Toolbar, and via the dropdown History-list in the top right-hand corner.
Opening all types of Components can be achieved via 'File->Open', which starts a Browse Form that enables you to select a Component type, or by simply typing in the Component name in the History-list.
Tags section
The Component Editor will expand Operations separately in the "Tags"-list when editing the Operations Trigger. Selecting individual Operation Tags will reposition the cursor to the relevant Operation in the Proc window. When editing, adding or removing Operations, the Operations Tags list will be updated. This expansion is available for:
Manual Tags, Find Tags and Syntaxerror Tags are also still available.
Toolbar and Popup menus
The Component Editor has a context sensitive Toolbar and Popup menus, and supports resizing of all controls by means of splitters that can be dragged.
Syntax highlighting
All Proc Editors support highlighting of UNIFACE Proc language elements. The following language elements are recognized:
| Text | words and characters which are not reserved for the proc language |
| Strings | double quoted strings. |
| Proc Statements and Functions | All words which are reserved by the proc language. |
| Functions | Special Functions like $result, $status etc. |
| Comment | Program documentation which does not influence the program flow. |
| Type | UNIFACE data types. |
For all different types the color is defined in the UNIFACE usys.ini file. If there is no color specified a default color will be used. For mathematical- and Proc functions the same color is used as for keywords. The color setup can be customized in "Setup..." on the Application Icon.
Keyword completion
Keyword completion is supported for all Proc Language elements. Pressing the <TAB> Key when typing an incomplete statement or function will give you the UNIFACE keyword that matches. The completion action itself is case insensitive. Typing "MESSA" or "Messa" will result in the same keyword "message" if the <TAB> key is pressed. When <SHIFT><TAB> is used, the Editor reverses the search. For instance when the keyword completion gives "message/warning", you can use the <SHIFT><TAB> to go to the previous hint, in this case "message/info".
In UNIFACE V8, Entity Subtypes inherit their Triggers from their parent. The following parent-child relationships exist:
- A Functional Subtype has a parent Supertype.
- A Component Subtype has a parent Functional Subtype or Supertype.
Field level Triggers are copied from the defaults, when a new Field is added.
In the Model Trigger Editor, this behavior will be indicated by the icon in front of the Trigger:
Trigger code is inherited from Supertype. Trigger is empty. Trigger has Proc code, not inherited. Trigger is a "local variation". Most Properties of Subtypes can not inherit, and will be copied from their parent, except for the Properties which are automatically kept in sync with the parent definition by the UDE. (See also: Customizing UNIFACE defaults.)
How does it work?
This inheritance mechanism works in the same manner as (and is in fact an extension of) the inheritance mechanism between the Business Object Model and Components, which has been part of the UNIFACE UDE for a long time: When a Trigger is empty, the inheritance mechanism will show the inherited contents of its parent. Changing inherited contents of a Trigger will break the inheritance and create a "local variation" of that Trigger. Inheritance can be restored by:
- Making the Trigger empty: On leaving the Trigger, the Trigger Editor will change the icon to show inheritance and you'll see the parent Trigger contents again.
- Double clicking on the Trigger in the Triggerlist: This will pop up a Form that shows the Supertype Trigger contents. On clicking 'OK', inheritance will be restored.
- When the Trigger has the same contents (after editing) as its Supertype, inheritance will be automatically restored by the Trigger Editor.
Note: When you want a Subtype Trigger to be empty, and not inherit from its parent, put in a semicolon (;), this will break the inheritance, but will preserve implicit behavior of the Trigger.
Exampes of implicit behavior in "empty" Triggers:
- Empty Exec Trigger does implicit "edit".
- Empty
<Remove Occurrence> Trigger does implicit "remocc" - Empty <Add/Inster Occurrence> Trigger does implicit "creocc".
Overlay Inheritance
As described, the inheritance mechanism used for UNIFACE Triggers follows the rationale "…If empty, then inherit..". However, for Triggers that act as placeholders for multiple operations or entries, UNIFACE uses an "overlay inheritance" mechanism. These Triggers are:
- All "Operation" Triggers (In Component Operations, Entity Occurrence Operations and Entity Collection Operations).
- The "Extended Triggers" Trigger for Fields.
The "overlay inheritance" mechanism works similar as the overlay mechanism introduced in UNIFACE V7.2 for inheritance of Operations from Component Templates to Components.
Local Proc modules ('entries') are not overlayed, in order to stay compatible to UNIFACE 7.
