Installer - Configuring Actions

     


  Actions are configured on the screens & and actions tab.

Please see the list of available actions that come with install4j.

  An action performs a configurable unit of work of the installer application.

Actions are attached to screens or they are part of the startup sequence that allows you to perform actions before the installer or uninstaller is displayed. If any of these actions fails and has a "Quit on failure" failure strategy, the installer application will not be shown.

  Common properties of actions are:
  • Condition expression
    This expression is evaluated just before the action is executed. If the expression or script returns false, the action will be skipped.
  • Rollback barrier
    If the action should be a rollback barrier. When a rollback barrier is completed, none of the preceding actions will be rolled back. You can use this property to prevent an incomplete rollback of complex changes or to protect actions from rollback when the user hits "Cancel" in the post-install phase.
  • Can be executed multiple times
    If the action can be executed multiple times. If unselected, the action will only be executed once and do nothing for subsequent invocations of the containing screen. The default settings for screens ensure that a screen with actions is only shown once. However, if the "Back button" property of a screen is changed of if you skip screens programatically, a screen with actions might be shown multiple times.
  • Failure strategy
    If an action fails (i.e. returns 'false'), the installer or uninstaller can continue, quit, or ask the user what to do. If you select something other than 'Continue on failure', you should enter an error message in the "Error message" property unless the action displays the error itself.
  • Error message
    If the action fails, this error message is displayed to the user, otherwise the action fails silently.
  Most often, actions are added to the "Installation" or "Uninstallation" screens. The advantage of those screens is that they have a progress and status bar that is utilized by actions. If a screen does not expose a progress interface, the status and progress messages of attached actions are lost. This is no problem for near-instantaneous actions such as setting an environment variable, but for time-consuming operations the user should be informed about progress, even if it is only an indeterminate progress bar. As an alternative to the "Installation" or "Uninstallation" screens, you can use "Display progress" screens to create additional installation phases.

Some actions have an "affinity" to a particular screen and will suggest to add themselves to that screen, such as the actions in the "Final options" category which would like to go to the "Finish" screen. However, this is only a suggestion to guide you for the most common use case.

Some actions have an associated screen that allows the user to modify the behavior of the action. For example, the "Install a service" action has a corresponding "Services" screen that allows the user to decide whether the service should be installed and started on bootup. If such a relationship exists, a corresponding notification is displayed after adding an action.