In Uniface 9, there are two types of trigger behavior:
- Implicit or default Uniface behavior;
- Explicit behavior
The most well-known example of implicit or default behavior is the execute trigger, which displays the component in edit mode, even if you do not declare it. Explicit behavior is all code that a developer writes. This explicit behavior will block default behavior even if you did not intend to. I cannot count the number of times I created an execute trigger and forgot to explicitly add the edit statement.
In Uniface 9, every trigger has its own code container and is validated by the compiler. In a way, all triggers are defined implicitly. The way to restore default behavior is to replace the (inherited) code in the trigger with a semicolon (sometimes followed by a comment). The semicolon breaks inheritance but does not implement any other explicit behavior. The compiler considers it to be empty and will disregard it during compilation. At runtime, Uniface will revert to its default behavior (if it has any).
In Uniface 10, we reduced the number of containers. An entity has a maximum of three containers; one for the declarations; one for the collection operations and one for the occurrence operations (and all other occurrence level modules, such as triggers). Fields, components, and application shells have only two; a Declarations container and a Script container. The Script container is where you store your triggers, operations and entries. There is no way to implicitly define a trigger anymore. Every trigger is either inherited or explicitly declared; in both instances, the trigger loses its default behavior.
Restoring the default behavior by using a semicolon in the trigger no longer works. During compilation, Uniface 10 will create a trigger that does nothing when executed. It still breaks inheritance but no longer restores the default behavior.
; this trigger breaks inheritance ; but does not restore the default behavior ; in Uniface 10 trigger detail ; end ; trigger detail
The only real solution to revert back to the default behavior is to convince the compiler to ignore all explicit behavior. For this purpose, we introduced the ‘undeclare’ keyword, which instructs the compiler to skip the compilation of the explicitly defined triggers, thereby restoring the default behavior:
undeclare trigger detail
Triggers can only be undeclared after they have been declared. When a trigger is undeclared before its declaration (or when it does not exist at all) the compiler will ignore the undeclare and issue a warning in the messages tab..
; first declare the trigger trigger detail askmess "detail trigger" end ; then undeclare it undeclare trigger detail
Undeclaring inherited triggers
A trigger that a component inherits from a modeled entity or field can be undeclared in Script container of the modeled object or in the Script container of corresponding derived object in the component.
The Script container of a modeled field contains the following code:
trigger detail askmess "detail trigger" end
The Script container of that same field on a component
undeclare trigger detail
This will result in the removal of the modelled detail trigger and will restore the default behavior (if it has any).
Undeclaring operations and entries
It is also possible to undeclare operations and entries:
operation myOperation ; some code end ; myOperation undeclare operation myOperation entry myEntry ; some code end ; myEntry undeclare entry myEntry
For operations, the same rule applies as for triggers; they can be undeclared in the modeled or the derived object, but it must be done in same code container. For instance, if an operation is declared in the Occurence Script container on the model level it can only be undeclared in the same container on either the model level or the component level.
For entries it works differently. Since entries have a component scope, the entry can be undeclared in every container that is compiled after the last time the entry was declared. This requires a deeper understanding of how the compiler works.