Migration Logicals

Determines whether a constant scope block (#startdefine and #enddefine) is added to a migrated, non-empty trigger definition, and to each group of migrated operations. This ensures that scope of these constants is limited to the trigger, and not the code container. For example:

#startdefine
#define $triggerAbbr=DTLF
trigger detail
...
end
#enddefine

By default, a constant scope block is added only when needed. It is not added to constant definitions in the Declarations script container, because they always have Component scope.

You can use this logical to change this behavior. Valid values are:

• 0—constant scope is not defined. This may affect application behavior in Uniface 10.
• 1—constant scope is defined for all triggers and operation groups, even if this is not required. This can make your code harder to read.
• 2—constant scope blocks are added only when the trigger contains #define, #include, or <$triggerAbbr> keywords. (default behavior)

Determines whether to add an end statement to migrated ProcScript modules, when necessary. For more information, see Migration of ProcScript.

• 0—do not add an end statement to modules
• 1 (default)—add an end statement

Determines whether to add a comment at the beginning and end of each migrated ProcScript module with the version 9 trigger name. This makes it easier for existing users to identify triggers that have been renamed.

• 0(default)—do not add comments
• 1 —Add comments with Uniface 9 trigger names

Determines whether non-functional code is migrated for components. In Uniface 9, it was possible for trigger containers to contain code that was not relevant for the component type (such as a Detail trigger in a Service) as a result of converting one component to another type. This code was not visible and not compiled into the component.

By default, such code is not migrated to Uniface 10 because entries defined these triggers would be compiled, thereby changing the application behavior.

You can use this logical to change this behavior. Valid values are:

• 0—non-functional code is migrated. This may affect application behavior in Uniface 10.
• 1—non-functional code is removed from normal components, but not from modeled components (formerly Uniface 9 component templates). Use this option only if component templates were converted to a different type of component template; for example, if a form template was converted to a service template.
• 2(default)—non-functional code is removed from both normal components and modeled components.

Determines whether the <$triggerAbbr> constant is defined at the start of migrated, non-empty triggers. By default, a trigger abbreviation is defined only when required (for example, when <$triggerAbbr> is used in the trigger code or IncludeScript).

For example, for the trigger receiveMessage (formerly Asynchronous Interrupt), the following instruction would be added:

#define $triggerAbbr=ASYN

You can use this logical to change this behavior. Valid values are:

• 0—trigger abbreviation is never defined.
• 1—triggerr abbreviation is always defined.
• 2 (default)—triggerr abbreviation is declared only if the keywords <$triggerAbbr> and #include are found in the trigger code.

If not defined, <$triggerAbbr> returns the code container name. In Uniface 10, triggers are explicitly declared in the script container. In Uniface 9, each trigger was implicitly declared by a dedicated code container, whose name was returned by <$triggerAbbr>. For more information, see Migrated Trigger Abbreviations.