Using a Sequence Table

[This is preliminary documentation and subject to change.]

The authoring of the sequence tables is an essential part of developing an installer package because these tables specify the flow of the installation process. Sequence tables are the only place in an installer package where the flow can be specified. The flow is always linear and there can be no branching or looping.

There are six sequence tables in the installer database:

• The InstallUISequence table
• The InstallExecuteSequence table
• The AdminUISequence table
• The AdminExecuteSequence table
• The AdvtUISequence table
• The AdvtExecuteSequence table

Upon the execution of one of the top-level actions, INSTALL, ADVERTISE, and ADMIN, the installer begins advancing through the sequence of actions listed in one of the user interface, execution, or advertise sequence tables. The installer contains internal logic that determines which of the sequence tables to use.

• The user interface (UI) sequence tables contain the exit dialogs and actions coming before the InstallValidate action. Actions from InstallValidate to the end of the install sequence are located in the execution sequence tables. The actions needed to advertise products and features are located in the advertise sequence tables.
• A typical UI sequence table will begin with costing initialization actions, then the user interface actions, and then the ExecuteAction action, which starts the execution of the installation. Here is an example of a sequence table.

The sequence tables have three columns: Action, Condition, and Sequence. The Action column names the standard or custom action, or user interface wizard, the installer will execute. The Sequence column indicates the place of the record in the sequence and each record in the sequence table is sampled in order. The Condition column is a logical expression that causes the action to be executed if the expression is True and skipped if the expression is False. Conditions can be thought of as jumps and so the linear flow may not execute every action.

The following actions in this sequence table are defined by the installer and are therefore examples of standard actions.

LaunchConditions
AppSearch
CCPSearch
CostInitialize
FileCost
CostFinalize
RegisterProduct
InstallFiles
InstallFinalize

The following actions were defined by the table's author and are therefore examples of custom actions and must be listed in the CustomAction table.

MyCustomConfig
MyCustomAction

The remaining entries in the Action field are dialogs. They therefore must be entries into the Dialog table.

CCPDialog
InstallDialog
MaintenanceDialog
ActionDialog

The Condition column causes the installer to skip the action if the property or expression in this field is False. The Installed property and the Resume property are example of properties that are set by the installer. The Installed property is set to true if the product is already installed and the Resume property is set if resuming a suspended installation. The CCP_TEST and the NOT_CCP_SUCCESS properties are examples of properties that can be set at the command line by the user installing the application.

All actions will therefore run in sequence with the following conditional steps.

• The CPPSearch is run only if CCP_TEST is set.
• CCPDialog is run only if NOT_CCP_SUCCESS is set.
• MaintenanceDialog is run only if this product is already installed and if this is not an installation that is being resume after being suspended.
• MyCustomAction is run only if the expression in the Condition column is True. The expression $MyComponent > 2 refers to the action state of the component called MyComponent. This condition indicates that MyCustomAction should only be run if MyComponent is set to be installed. For more information on Action states and Selection states, see the FeatureRequestState property, the Feature table, and the InstallFiles action.

For more examples of properties see Using Properties and for more information on how expressions are evaluated see MsiEvaluateCondition.