Installer - Configuring Screens

     


  For more information on screens and related concepts, please see the corresponding help topic.
  Screens are configured separately for the installer and the uninstaller. The drop-down list above the list of screens allows you to select the installation mode for which the screens should be displayed.

Some screens only make sense when corresponding actions are used later on in the installer or uninstaller. For example, the "Services" screen will only be displayed at runtime if there are "Install a service" actions present on a subsequent screen. If such a dependency is not fulfilled after adding a screen, a corresponding notification is displayed.

Screens have actions attached. To quickly jump to the attached actions of the selected screen in the actions configuration, you can use the  [Go To Action] tool bar button.

  On the left side you see the list of currently configured screens. The  [Add] button shows a popup window where you can select whether to add
  • a standard screen, i.e. a screen from the list of default screens that is made available by install4j or a screen that is contributed by an installed extension. A registry dialog will be shown where you can select the desired screen.
  • a screen that is contained in your custom code. New types of screens can be developed with the install4j API. In your custom code configuration you can specify code locations that are scanned for suitable classes. A class selector will be shown where you can select the desired class.

If you select a single screen in the list of screens, you can edit its properties on the right side, if you select multiple screens, you can copy them to the clipboard or delete them with a single action. If your selection is a single contiguous interval, you can move the entire block up or down in the list.

  After you add a screen, the list of screens shows it with its type display name. This is often enough, however, if you have multiple instances of the same screen alongside, a custom name makes it easier to distinguish these instances. You can assign a custom name to each screen with the  [rename] button. The type name is still displayed in brackets after the custom name. To revert to the default, just enter an empty custom name in the rename dialog.
  install4j offers an inter-process clipboard for screens. You can  [cut] or  [copy] screens to the clipboard and  [paste] them in a different instance of install4j. Note that references to launchers or references to files in the distribution tree might not be valid after pasting in this case. Pasted screens are appended to the end of the list unless sequence restrictions with respect to the the already present screens force a different order.
  Common properties of screens are:
  • Condition expression
    This expression is evaluated just before the screen is shown. If the expression or script returns false, the screen will be skipped.
  • Validation expression
    This expression or script is called when the user clicks the next button. If it returns false, the current screen will be displayed again. You can use this to validate user input. Error messages are not displayed automatically, you can use the Util.showErrorMessage(String errorMessage) method in your script.
  • Rollback barrier
    If the screen 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. The installation screen is a rollback barrier by default.
  • Quit after screen
    If the screen should have a "Finish" button instead of a "Next" button. The installer or uninstaller will quit after this screen. The "Cancel" button will not be visible if this option is checked.
  • Back button
    Allowing the user to go back to previous screens can be problematic if the previous screen has actions attached, since by default every action is just executed once. The default behavior is the "Safe back button", where the back button is hidden if the previous screen has actions attached. If you configure your actions to be executed multiple times, you might want to choose the "Always visible" setting. With the "Always hidden" setting you can prevent the user from going back to the previous screen.