Uniface 10: Changes in ProcScript Inheritance

In Uniface 10, there are no longer separate containers for triggers. Instead, triggers, operations, and entries are defined in a single script container of the associated object. As a consequence, ProcScript in Uniface 10 is inherited per script module, rather than per trigger container, as was the case in Uniface 9.

In module-based inheritance, components, entities, and fields inherit any triggers, operations, and entries declared in the objects on which they are based (such as modeled entities, subtype entities, and modeled components). You can break inheritance by defining a local ProcScript module of the same type and name.

In container-based inheritance, objects inherited the entire container, which might hold multiple ProcScript modules, such as triggers and entries. By defining anything in the local container, you broke inheritance for all the ProcScript modules in the container.

Inheritance in Uniface 9

Prior to Uniface 10, module inheritance was used for Operations, but container inheritance was used for Extended Triggers containers and Local Proc Modules container and standard triggers such as the store trigger. Although not good practice, standard triggers (which were containers that implicitly declared the trigger) could also contain entries.

In container inheritance, if any local content is defined in the container, the complete content of the container (as defined in the modeled object) is replaced. If there were entries in the container of the modeled object that you wanted to use, you needed to redefine them all locally. Alternatively, you may have relied on this behavior to suppress entries or break trigger inheritance.

Container inheritance is all or nothing. For example, if the Read trigger of a modeled entity held both trigger code and one or more supporting entries, it was not possible to overlay the Read code but inherit the entries.

Inheritance in Uniface 10

In Uniface 10, standard trigger containers and Local Proc Modules containers no longer exist. Instead, each object has one or two Script containers for all ProcScript modules, and all modules are explicitly declared, whether they are a standard trigger, extended trigger, operation or entry.

All ProcScript modules, including triggers, entries, and operations, now use the overlay inheritance model. This means that after pre-compilation, local definitions are added to inherited definitions, and duplicate modules are overlaid by the last module added, resulting in a single set of modules per object. For more information, see Inheritance.

Ensuring Compatibility

Changing the way ProcScript modules are inherited makes inheritance consistent and predictable, but it could affect your migrated application, especially entries.

To ensure compatible behavior between Uniface 9 and 10, the migration utility adds precompiler directives to prevent triggers and entries from being inherited in cases where both the following conditions are met:

  • The standard trigger or Local Proc Modules container contains entry definitions or #include statements (which might include entry definitions).
  • The code container is specialized on a lower level.

Although this maintains compatible compilation and runtime behavior between Uniface 9 and 10, it may make your code harder to read and understand.

You can override this behavior by setting the migration logical MIGRATION_SCRIPT_V9_INHERITANCE = 0. For more information, see Inheritance and Compilation of Migrated Entries.