Response File Dialog Data

InstallShield 2019

Project • This information applies to the following project types:

The last block of information in a response file is the response file dialog data. The response file dialog data is a collection of sections containing the values returned by each dialog identified in the dialog sequence section. Each dialog has its own section. The values listed are the same values that the dialog returns in a normal end-user input-driven installation. You can also create dialog data sections for custom dialogs.

The format for a dialog data section is shown below:

[<PRODUCT_GUID>-<DialogIdentifier>]

Result=value

Keyname1=value

Keyname2=value

The [<PRODUCT_GUID>-<DialogIdentifier>] section header identifies the specific dialog and is followed by the dialog data entry list. <DialogIdentifier> is the same expression used to list the dialog in the dialog sequence section.

Data entry items are in the format keyname=value. The keyname is a name for a value returned by a dialog and recorded in the response file. All dialogs, including custom dialogs, return a value for the keyname Result, reflecting the button that was clicked to end or exit the dialog. Many dialogs will also set or return a value in a variable.

For example, in a non-silent installation, the AskDestPath dialog returns the destination location in the svDir parameter. The line in the script might look like the following:

nResult = AskDestPath( szTitle, szMsg, svDir, 0 );

The corresponding dialog data entry in the Setup.iss file for a silent installation might look like the following:

[{23EAFFCA-361D-11D3-8B0F-00105A9846E9}-AskDestPath-0]

Result=1

szPath=C:\Program Files\InstallShield\2019

In the above example, Result=1 is equivalent to clicking the Next button in the dialog, and szPath=C:\Program Files\InstallShield\2019 is the value returned in the svDir parameter of AskDestPath.

The name of the variable used in the script is meaningless relative to the Setup.iss file. However, in the Setup.iss dialog data sections, each built-in and Sd dialog has its own set of keynames that map to its parameters. The keynames are important and must be exactly as defined for each dialog. Refer to Dialog Data Keynames List, below.

When you use custom dialogs, you must create a dialog data entry for the Result keyname for each dialog, plus entries for any other values set or returned by the custom dialogs. Use the Dialog Data Keynames List, below, as an indicator of how to create keyname=value expressions for your custom dialogs. Call GetProfString or GetProfInt to read the dialog data information for the custom dialog. GetProfString and GetProfInt allow you to specify the .iss file, the section, and the keyname, and they return the value assigned to that keyname.

Standard Values for the Result Keyname

All dialogs, including custom dialogs, return a keyname value called Result, indicating which button was clicked to end the dialog. Unless otherwise indicated, the Result standard values are:

Recording Component and Subcomponent Selections

Some dialog functions allow the end user to select components and subcomponents. There are three kinds of dialog data keyname entries used to record component and subcomponent selections in response files: type, count, and <#> (described below).

Every set of component selections and every set of subcomponent selections has one type keyname entry, one count keyname entry, and as many <#> keyname entries as are required to document each individual component or subcomponent selection.

When you are creating keynames to record component selections, precede the type, count, and <#> keyname entries with the word Component, thus:

Component-typeComponent-countComponent-0

When you are creating keynames to record subcomponent selections, precede the type, count, and <#> keyname entries with the name of the component to which the subcomponents belong, thus:

Program Files-typeProgram Files-countProgram Files-0Program Files-1

To create complete value entries, use the equal sign to attach the values to the keynames. (The types of values assigned to each kind of keyname are described below.) The following example shows complete value entries for two components, Program Files and Binary Files, and two subcomponents of Program Files, Executables and Support Elements:

Component-type=string

Component-count=2

Component-0=Program Files

Component-1=Binary Files

Program Files-type=string

Program Files-count=2

Program Files-0=Executables

Program Files-1=Support Elements

The type keyname indicates the data type of the components or subcomponents list. Since InstallShield dialogs currently use only string lists for components and subcomponents lists, type is always equal to string, as in Component-type=string. Future versions may use number lists, in which case type could equal number.

Count Keyname Entry

Count is equal to the number of selections for a given component or subcomponent entry. For example, if two components were selected for installation in the ComponentDialog dialog, the count dialog data entry would be Component-count=2. If two subcomponents of the Program Files component were selected, there would be a Program Files-count=2 entry.

<#> Keyname Entry

The number portion of the <#> keyname entry is simply a sequential (one-up) number, beginning with 0, that numbers each recorded component or subcomponent selection. Since numbering begins with 0, the greatest number value will always be one less than the value of count.

The value assigned to a <#> keyname entry is the selected component’s or subcomponent’s visible name (the string passed as the second parameter to ComponentAddItem when the components or subcomponents list was built).

For example, assume the ComponentDialog dialog offers end users a component selection of Program Files, Help Files, Sample Files, and Utilities. If the end user selects Program Files and Help Files, then the dialog data section for that instance of the ComponentDialog dialog will have two list item entries and will look something like this:

[{23EAFFCA-361D-11D3-8B0F-00105A9846E9}-ComponentDialog-0]

szDir=C:\MYAPP\FILES

Component-type=string

Component-count=2

Component-0=Program Files

Component-1=Help Files

Result=

The following example shows how subcomponent list selections are recorded. The example is for an instance of the SdComponentMult dialog. The example shows that two components—Program Files and Help Files—were selected. It also shows that four subcomponents were chosen: Main Files, Aux. Files, Main Help, and Tutorial Files. Main Files and Aux. Files are subcomponents of Program Files, and Main Help and Tutorial Files subcomponents of Help Files.

[{23EAFFCA-361D-11D3-8B0F-00105A9846E9}-SdComponentMult-0]

Component-type=string

Component-count=2

Component-0=Program Files

Component-1=Help Files

Program Files-type=string

Program Files-count=2

Program Files-0=Main Files

Program Files-1=Aux. Files

Help Files-type=string

Help Files-count=2

Help Files-0=Main Help

Help Files-1=Tutorial Files

Result=1

Dialog Data Keynames List

The dialog data keynames for the InstallShield dialogs are listed in the table below. The first column contains the dialog names. The second column lists the keynames applicable to each dialog. The third column contains descriptions of the values associated with the keynames.

Special Handling for SdFinishEx

SdFinishEx calls either SdFinish or SdFinishReboot, depending on the value of the system variable BATCH_INSTALL. For this reason, SdFinishEx cannot be handled by a response file. To create a silent installation for a script that calls SdFinishEx, use script code such as the following:

if (MODE = NORMALMODE) then

    SdFinishEx (szTitle, szMsg1, szMsg2, szOpt1, szOpt2, bvOpt1, bvOpt2);

else

    if !BATCH_INSTALL then

        /* Set bvOpt1 and bvOpt2 to the values you want them

        to have during a silent installation that does not require

        rebooting; for example: */

        bvOpt1 = FALSE;

        bvOpt2 = TRUE;

    else

        /* When the silent installation requires rebooting,

        if you want to reboot immediately call

        the System function as follows: */

        System (SYS_BOOTMACHINE);

    endif;

endif;

See Also

Understanding When an Installation or Uninstallation Restarts the Target System

Open topic with navigation