Frequently Asked Questions about package User Interface

Surveys show that users don't enjoy installing software, they endure it, thus a modern approach is to make setup as simple and lightweight as possible.

To achieve this from the Dialog Editor Page in a new project you'll need to:

• remove “WelcomeDlg” and “VerifyReadyDlg” dialogs
• choose which of the mutually exclusive “FolderDlg” and “SetupTypeDlg” better suits the single dialog role
• select “ExitDialog” and from the Finish Actions tab configure the launch application action while enabling the "Run finish actions without displaying this dialog" option

The built installer will prompt for the installation type and/or for the installation folder, install the package showing progress and launch the application to notify the installing user setup has ended.

Any dialog can be added after "SetupTypeDlg". The principle is the same like for any other dialog. With "SetupTypeDlg" selected use the [ Add Dialog... ] or [ New Dialog... ] toolbar buttons. The same options are available from the context menu once the dialog is selected.

This requires an Enterprise or Architect project.

The "SetupTypeDlg" and "FolderDlg" dialogs are mutually exclusive because they have the same purpose and they offer the same functionality. While "FolderDlg" allows you to simply set the installation path, "SetupTypeDlg" offers a little more through the "Custom" option (the "Typical" and "Complete" options use the default installation path).

The Dialogs and Prerequisites Repository default path can be changed from the Ribbon menu -> Options -> Repository Manager.

You can create a custom checkbox by following these steps:

• make sure you are using an Enterprise or Architect project
• go to the Dialogs page
• create a new dialog or select an existing one
• create a checkbox on it
• in the Text field from the Properties pane set the text of the checkbox
• in the Property Name field from the "Properties" pane set the property of the checkbox (for example CHECK)

The property of this checkbox can now be used to condition any project element which has a condition field :components, custom actions, feature install levels, chained packages, environment variables, SQL Scripts, scheduled tasks, IIS elements, Windows Firewall settings etc. For example you can set the Install Condition to CHECK. This way when the checkbox is enabled the condition validates and when the checkbox is disabled the condition is not met.

This can be done by using the EXE bootstrapper. First, you can add the languages you want by using the Languages tab of the "Translations" page. You should also make sure that you are building a multi-language package. After that, in the Configuration tab of the Build page you can check the Create EXE setup file option and select Display language selection dialog (for multi-language packages).

When the installation is launched through the EXE bootstrapper, it should show a language selection dialog. The available languages are the ones selected in the "Translations" page.

Windows Installer properties are global variables that Windows Installer uses during an installation.
There are two main types of Windows Installer properties:

• Private Properties (contain lower-case letters in their name, example: My_Prop)
• Public Properties (contain only upper-case letters in their name, example: MY_PROP)

The difference between Public and Private properties consists in the way their values are being passed on. Only the value of a Public Property is passed on from the Wizard Dialogs Stage (in which the dialogs are showed) to the Install Execution Stage (in which the system is modified).

Therefore, make sure that you use a Public Property for an UI control (Editbox, Combobox etc) if you want its value to be available in the InstallExecute Sequence (for instance, if the value of this Property is written in the registry, .ini file), otherwise you will get the default value assigned to this property.

Just make sure you are using a DLL custom action, and not a VBScript/JScript one. If you are using a VBScript or JScript custom action, you will need to convert it into a DLL custom action in order for the properties to get passed to Install Execution Stage.

This is a Windows Installer limitation. A public property set during Install Execution Stage cannot pass its value to the Wizard Dialogs Stage.

To workaround this issue you can schedule the custom action that sets the property during the Wizard Dialogs Stage.

This could happen if Windows Installer does not recognize the format used to save the RTF file. To solve the problem open the RTF file using WordPad and use "Save As.." option to obtain a new file, then use this file in your setup project.

The functionality is default on Azure theme but can be implemented on any other theme by following these steps:

• make sure you are using an Enterprise or above project type
• go to Themes page -> Settings tab and enable Enhanced User Interface
• go to Dialogs page -> "LicenseAgreementDlg" and replace the existing AgreementText ScrollableText control with a new one from the toolbox
• set this control's Property Name to EulaRead
• select the control with "IAgree" attached property name and set its Enabled attribute to False
• while the same control is still selected, add a new control condition from its Control Conditions tab (Condition: EulaRead ; Action: Enable)

This will ensure your users read the whole license agreement before they continue with the installation.

Sometimes, because of the format of the RTF file, the "I Agree" control may be enabled before the EULA was entirely displayed. In order to enforce more lines to be read, you can go in the Install Parameters page and create the AiEulaReadIgnoredLines property with a value smaller than 5. For instance, a value of -1 will enforce all the lines to be displayed from an EULA file, but the exact value may differ for another EULA because of the different RTF file formatting.

This happens because any other than "Classic" theme requires the Enhanced User Interface feature to be enabled. This feature is handled by our EXE Bootstrapper, but not by the MSI package. The "Enhanced User Interface" option can be found in the Themes page, Settings tab.

So, when you choose a theme, from the Themes page, that requires Enhanced UI, the package type is automatically turned to an EXE type in the Build page. Then, when the project is built it creates an EXE setup file and the MSI file next to it (the MSI file can also be included in the EXE file).

When you run your package, you should run the EXE file for the Bootstrapper to handle correctly all the dialogs and controls.

When you add an HTML Host Control on a dialog or you customize the dialogs appearence starting from HTML based theme like Spring, the rendering engine used to emulate the HTML content is Internet Explorer 7.

For compatiblity reasons, Microsoft implemented this limitation in the IWebBrowser2 API we currently use.

When using the LicenseAgreementDlg on the Black Surface theme, the backgroud of the EULA appears with a black shade which makes the text to be hard visible. To overcome this limitation, you can add another Scrollable Edit Box control with the same EULA document. You can change the font of the new EULA from the attributes of the Scrollable Edit Box control.

For the old control, you should set the Visible flag to False. This way, the user will not see this control. The old EULA will be used for printing while the new EULA with font changed will be seen by the user during installation.

In order for the UAC to display the package icon configured in Builds page you have to make sure the elevation is made at the beginning of the installation by the EXE Bootstrapper. This can be achieved using "Run as Administrator" option from Install Parameters. Also, the elevation is made by the EXE Bootstrapper if Enhanced User Interface is enabled in Themes Page, even if "Run as Administrator option is not enabled".

Otherwise, if the elevation is made by Windows Installer, the Windows Installer icon will be displayed.

This happens due to a limitation in our application's design. The changes to the Default Strings are saved in a special dictionary that is loaded when the .AIP project is reopened, thus the workaround would be to reopen the project.

There are some Windows limitations regarding our SVG support. To make sure your SVG image is compatible, check the complete list of supported SVG elements, attributes and features in this article: SVG Support