Uniface 10: The Uniface IDE

New editors are provided for creating projects, entities, components, and libraries of code snippets, IncludeScript, and Global ProcScript. These editors are non-modal, so it is possible to have many objects open for editing at the same time, and switch between them simply by clicking a tab.

In the new editors, you create new objects by dragging a template or modeled object from the Resource Browser on the left of the editor and dropping it onto the central editing pane. You can edit the properties of an object in the Properties Inspector, located on the right of the editor. For more information, see Resource Browser and Properties Inspector.

To open one of the new editors, you must first create a new object in a Project, then open the object from Project Editor or use the U-Bar to browse for the object you want to edit. To add sub-objects (such as new fields in an entity), you can usually drag a template from the Resource Browser and drop it onto the parent object in the editing pane. For more information, see Uniface IDE and Find and Open Objects Using the Main U-Bar.

Modifications to objects maintained in the new editors are automatically saved. When modifying properties, the change is saved when you press Enter. When editing script, data is saved when you pause in typing, and when you give focus to another object or property. The Script Editor and Layout Editor support Undo and Redo actions using Ctrl+Z and Ctrl+Y. For more information, see Save New and Modified Objects.

Important: When you delete objects, they are really deleted and cannot be recovered.

Editing object properties has now become much easier. All properties of a selected object are shown in a categorized list in the Properties Inspector. This provides a complete overview of all the properties an object has, and it is obvious which properties are read-only and which ones can be modified because the values of read-only properties are dimmed.

The Properties Inspector enables you to perform actions that were achieved by special menu options and dialogs in Uniface 9, or were not possible at all. For example, you can:

• Convert to another component type simply by changing the Component Type property. This can obviously have other consequences, such as the need to change widgets and ProcScript but does make it easier to convert a desktop application to the web, or to separate business logic from the user interface.
• Update properties of multiple objects by selecting multiple sub-objects. For example, you can select several fields in a component and change the widget type to the same value for all of them. For more information, see Edit the Properties of Multiple Objects.
• Sort the properties of an object by name. For more information, see Sort Objects and Properties.

The code of components, entities, fields, and application shells is now organized into one or two code containers in which all ProcScript modules, including triggers, are procedurally declared.

In Uniface 9, code was organized into many trigger containers that implicitly declared the trigger. However, some so-called triggers, such as Local Proc Modules, Operations, and Extended Triggers, were not triggers at all, but simply containers for multiple ProcScript modules.

The new organization makes module declaration and inheritance consistent for all ProcScript modules. For more information, see Code Containers andUniface 10: Changes in ProcScript Inheritance .

The new entity and component editors include a Compiled Modules Inspector that enables you to navigate to the script modules that are actually compiled into a component, no matter where they are defined. This makes it much easier to debug the code. For more information, see Compiled Modules Inspector .

All triggers are explicitly defined in the Script code container using the trigger ProcScript command. As a result, the terms standard triggers and extended triggers no longer have a meaning. When discussing triggers, it is more useful to distinguish between system triggers, which are executed in response to system events and interactive triggers, which are fired in response to user-initiated actions. For more information, see Script Modules and Triggers.

The names of many triggers have been changed to better reflect their purpose. For example, the Asynch Interrupt trigger is now receiveMessage, and Get State and Set State are now preActivate and postActivate.

The Execute trigger is now defined as an exec operation. During compilation, For more information, see Uniface 10: Changes in Triggers.

Relationships are child objects of entities. In Uniface 10, relationships between modeled entities are defined in the Many entity of a One-to-Many relationship, rather than in the One entity. This makes it easier to edit the foreign key field, which must be defined in the Many entity. For more information, see Define Relationships Between Modeled Entities.

In Uniface 10, there are some changes in the properties and behavior of modeled and derived components (formerly known as component templates and attached components).

• New properties are available for modeled components and generic entities and fields, such as Is Generic, Is Bound, and Bound to
• Component variables are now inherited by the derived component. In Uniface 9, these were separate objects that were not inherited.
• Generic entities and fields are bound to component entities and fields simply by renaming them. If the new name is the name of modeled entity or field, it inherits from the modeled object.

  As a consequence, you can change the binding to a different entity or field. This was not previously possible.

• In a derived component, it is possible to edit the Bound to component property. This enables you to complete break the inheritance to the modeled component, or to have it inherit from a different modeled component. This was not previously possible.

For more information, see Modeled Components.

Modeled properties (formerly entity interface templates, field interface templates, field layout templates, and field syntax templates) are now created in typed libraries with the fixed name LIB.

In Uniface 9, they were defined as independent objects.

Component variables are now declared procedurally in a variables block in the Declarations code container of components. In Uniface 9 they were defined declaratively as a separate object. For more information, see Component Variables, variables…endvariables, andMigration of Component Variables.

Global constants are defined in a reserved IncludeScript called DEFPARAM using the #define directive. Each IncludeScript library can contain a DEFPARAM ProcScript for defining global constants. To be truly global for all your Uniface applications, global constants should be defined in the SYSTEM_LIBRARY.

There is no longer a separate editor for defining global constants. The global constants are automatically exported when the parent library is exported. When exporting from Uniface, it is no longer possible to specify constants as an object type for export (using $ude ("export" or the Export form).

Compile-time constant declarations (#define directives) in Script containers have container visibility (or scope), so they are applicable for all triggers, operations, and entries in a Script container. In Uniface 9, they had trigger visibility.

To narrow the scope to a specific script module, or even to a group of modules you can use the new #startdefine and #enddefine precompiler directives.

For more information, see Migration of Global Constants, Constants, and #startdefine.