Active Path for Runtime Processing
The active path determines where processing is applied in a runtime component, and the order in which it occurs. It leads from the current occurrence of the outermost entity down to the current occurrence of the innermost entity.
For example, the following illustration shows active path to the current occurrence in a component instance, in which one entity is nested inside another. It traces a path that goes from the OUTER.ENTITY collection, to the second occurrence of the OUTER.ENTITY, then to its INNER.ENTITY collection, and finally to the first occurrence of the INNER.ENTITY.
Active path
Note: For Form components, the active path continues to the currently active field, which is the field that gets focus once the application becomes idle.
Most ProcScript instructions work in some way on the active path. For example $occmod() returns the modification status of the current occurrence of the specified entity, whereas clear/e "INNER.ENTITY" clears the collection of occurrences of the specified entity within the current occurrence of its parent entities.
Changing the Active Path
The active path can be changed in a number of ways:
- Explicitly by the end user. For example, setting the focus to a field makes its stack of occurrences part of the active path.
- Explicitly using ProcScript commands. For example, setocc changes the current occurrence within its current collection.
- Implicitly by the Uniface runtime engine. For example, activating an operation via the handle to an occurrence or a collection that is currently not in the active path, changes the active path to that occurrence or collection for the duration of the operation's execution. After that, the original active path is restored.
ProcScript that Changes the Active Path
In addition to setocc, some ProcScript commands can (temporarily) change the active path. For example:
- creocc
- remocc
- moveocc
- discard
- compare/next
- forentity
- read
- delete
- retrieve/o
- retrieve/x
- sort
