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:
  • Action elevation type [Privileges]
    If the action should run in the elevated helper process.An elevated helper process is available on Windows and macOS if the process has been started without admin privileges and the "Request privileges" action has been configured to require full privileges.
  • Condition expression [Control Flow]
    This expression is evaluated to decide whether the action is executed. If the expression or script returns false, the current action will be skipped. This expression or script should not have any side-effects, it will be called while another screen is still being displayed.
  • Rollback barrier [Control Flow]
    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.
  • Exit code [Control Flow]
    If the "Rollback barrier" property is selected, and a rollback terminates at this action, this property determines the exit code of the installer. By default, reaching a rollback barrier during a rollback is considered a success, but you can signal a failure by specifying a non-zero exit code here.

    Note: This property is only visible if "Rollback barrier" is selected.

  • Can be executed multiple times [Control Flow]
    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 that cannot be executed multiple times is only shown once. However, if the "Back button" property is changed of if you skip screens programmatically, a screen might be shown multiple times.
  • Failure strategy [Error Handling]
    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.

    For "Return to the parent screen", no further actions will be executed and the previous screen will be displayed again. If the action is contained in the "Startup" node, the first screen will be shown and in unattended mode the application will quit.

  • Error message [Error Handling]
    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.