and choose Generate GUID from the menu. This will generate and insert a GUID (Globally Unique IDentifier) that is "to a very high degree of certainty" guaranteed to be different from all other GUIDs generated in a similar manner.The Installation page establishes the basic installation parameters. Specifically, it lets you specify where your application should be installed, whether or not an uninstaller should be registered with Windows, and which privileges are required to install your application under Windows NT.
The Installation locations fields define the primary installation locations for your application. They form the basis for the more detailed installation structure that you define elsewhere in the project.
Enter the symbolic path to the installation folder for your application. The default value for this field is
<ProgramFiles>\<Company>\<AppTitle>
in accordance with the Microsoft Windows guidelines. However, many applications use the shorter variation
<ProgramFiles>\<AppTitle>
Do not use absolute paths here; instead, start the path with <ProgramFiles> to make sure that your application ends up in the Program Files folder on the customer's computer (which need not be C:\Program Files - the actual location depends on the computer's configuration and the language of the Windows version installed on that computer).
If nothing else, the Setup.exe program and its Setup.ini database are always installed in the application folder. Furthermore, you should also install the main application files in this folder, or in a folder below it. If any portion of your application must be installed elsewhere (for example, in the Windows System folder), you can deal with those files separately on the Project - Files page.
Tip - The value of this field is available through the <AppFolder> project variable throughout the rest of the project.
Check this box to allow the customer to browse for a different installation folder during the installation process. If you leave the box blank, this functionality is disabled and your application will always be installed in the location that you entered under Application folder.
Check this box to append the base folder name (the rightmost component of the default Application folder path) after the customer has browsed for the installation folder; clear it to leave the installation folder name as it is returned by the Browse for Folder dialog. If the chosen folder path already ends with the base name, it is left unchanged regardless of this option.
The Browse for Folder dialog can only select existing folders such as C:\Program Files, and in many cases it is desirable to create a new installation folder, for example C:\Program Files\MyApplication. The Append base folder name option is designed to make this easier by automatically appending the final name if it isn't already there. However, if your requirements are different, you can clear this box to prevent the automatic append.
Check this box to have Setup create a program group for your application. This allows you to install shortcuts in the program group; see Project - Shortcuts for details. If this box is cleared, no program group is created, but you can still install shortcuts in other locations.
Enter the name (symbolic or literal) for the program group that will appear on the customer's Start > Programs menu. Typically, you will use the application title, which is why the default value for this field is <AppTitle>.
Tip - If desired, you can create the program group in a subfolder by simply specifying an extra level in the program group's name. For example, <Company>\<AppTitle> would create a <Company> folder on the Start > Programs menu, with an <AppTitle> subfolder in it. All shortcuts marked for installation in the program group would then end up in this subfolder.
Tip - The value of this field is available through the <ProgGroup> project variable throughout the rest of the project. The full path to the program group folder is available as <ProgGroupDir>.
Select this option to let Setup check that the listed processes are not active during installation or removal of your application; this reduces the chance of in-use files later on. The running processes check option has three values:
After selecting the second or third value, enter the names of the processes that Setup should check for. The name of a process is the name of its executable file; for example, Microsoft Excel would be excel.exe, Microsoft Word is winword.exe, and the Tarma QuickInstall build environment is tin.exe. You may enter more than one process name by separating them with semicolons (';'); Setup will check all of the listed processes and report on each one individually. For example, to check that none of the Microsoft Office applications are running during installation, you could specify:
excel.exe;msaccess.exe;powerpnt.exe;winword.exe
Note - The running processes check is not implemented on Windows NT4; on that platform, no check is performed.
Check this box to have Setup check if it runs with Administrator privileges on Windows NT. (This option has no effect if Setup runs on Windows 9x, where all users have unrestricted access to the system.) Administrator rights are required for many installation-related operations on these systems, for example:
Because it is very difficult to avoid all these situations, it is recommended to let Setup run with Administrator privileges on Windows NT platforms. Setup will check for the required privileges and ask the customer to re-run Setup if insufficient privileges are available. This applies to installation runs, but also to (optional) post-boot registration runs, and to uninstallation runs. (See Overview of the Setup process for an explanation of the various Setup run modes.)
Check this box to suppress any warnings about files that are in use during installation; clear it to warn the customer if in-use files are found. This warning is useful to give the customer an opportunity to close other applications that might be using the file in question. However, some files are held by system processes or other processes over which the customer has no control, in which case the warning is confusing at best.
Note that if any in-use files are encountered during installation, Setup will automatically schedule a reboot when the installation is complete, regardless of the Suppress in-use warnings option. Refer to Installation actions for more information.
Check this box to let Setup schedule a system restart at the end of the installation process, regardless of any other circumstances. (The customer still has to approve the restart.) Setup automatically schedules a restart in the following situations:
These situations cover the most common scenarios and will only restart the system if absolutely necessary. Unless you have a very good reason to the contrary, it is therefore recommended not to schedule an unconditional reboot. This keeps the disruption to the customer to a minimum.
Check this box to let Setup delete its log file after successful installation or uninstallation; clear it to retain the log file. If the installation or uninstallation fails, the log file is retained regardless of this option.
Tip - The installation log file is stored in the Temp folder of the installing or uninstalling user. On Windows 9x systems, this is usually C:\Windows\Temp or C:\Temp; on Windows NT4, this is usually C:\Temp; on Windows 2000 and later, this is usually C:\Documents and Settings\user-name\Local Settings\Temp.
Click this button to open the Installer Error Handling dialog box. This dialog box lets you set options that determine how Setup deals with errors during the installation process.
The Finish page fields set options for the Setup - Installation completed page.
Check this box to include a Start the application option on the Setup - Installation completed page; clear it to omit that option. If you check this box, you should enter the path of the application file to run after installation; if necessary, use the ... (browse) button to browse for an installation file.
Unless the customer cleared the Start the application box, the application in question is started after the customer clicks the Finish button on the Setup - Installation completed page. However, if a system restart is necessary, the entire option is suppressed.
Note - Although this option is useful to start your application immediately after installation, for example for post-installation configuration or simply to save the customer the trouble of having to locate the application's shortcut, you should be aware that the application will be started in the context of the installing user account. On Windows 9x systems, this is rarely a problem; on Windows NT systems, however, this might mean that your application is started under an Administrator account, which need not be the customer's normal login account. Therefore, if your application stores per-user settings, they may end up under the wrong user account.
Enter any command line arguments that your application requires to run; leave the field empty if your application requires no arguments.
Enter the working directory for the application.
Check this box to include a Show the Readme information option on the Setup - Installation completed page; clear it to omit that option. If you check this box, you should enter the path of the Readme file that you want to show; if necessary, use the ... (browse) button to browse for an installation file.
This option is useful to display any post-installation release notes; for pre-installation information, you should use Tarma QuickInstall's Installation - Readme information feature.
Unless the customer cleared the Show the Readme information box, the file in question is opened after the customer clicks the Finish button on the Setup - Installation completed page. However, if a system restart is necessary, the entire option is suppressed.
Tip - You are not restricted to plain text files; Setup uses the ShellExecute() Windows function to open the file, which means that you can use any document type that is registered on the customer's computer. In addition to .txt files, this usually includes .rtf (Rich Text Format), .htm (HTML files), and .doc (Microsoft Word documents). WinHelp files (.hlp) or compiled HTML Help files (.chm) are other possibilities. If you use a fully qualified URL, for example http://www.tarma.com/, you can even use this option to connect to a web site after installation.
The Uninstaller options fields determine the behavior of the uninstaller.
Check this box to have Setup register itself as the uninstaller for your application as part of the installation process. If this box is clear, no uninstaller is registered and the customer cannot uninstall your application, unless you provide some alternative means. (See Uninstaller information for the details of what uninstallation information gets registered with Windows.)
Enter the name for the uninstaller key that is registered with Windows. This key is simply a text string that Windows stores in its registry, along with information about the program that uninstalls your application (in this case the Tarma QuickInstall Setup program).
The main requirement for the uninstaller key is that it must be unique among all applications for which Windows stores uninstaller information. Usually, the application title is a good attempt at this, which is why the default value for this field is <AppTitle>. However, if you have special requirements (for example, backward compatibility), you can enter any other text here.
Note - As of release 2.70, Setup.exe, Setup.ini, and other Setup support files (bitmaps, extension DLL) are no longer installed if you clear the Uninstaller key box. Therefore, no uninstaller is available to the customer. As a side effect, delayed file registration is also disabled because that requires Setup.exe to be installed on the customer's system. Normal file registration (i.e., as part of the installation process proper) is not affected.
Tip - If you want to make absolutely certain that your uninstaller key is indeed unique, click on the variable popup button and choose Generate GUID from the menu. This will generate and insert a GUID (Globally Unique IDentifier) that is "to a very high degree of certainty" guaranteed to be different from all other GUIDs generated in a similar manner.
Tip - The value of this field is available through the <Uninstall> project variable throughout the rest of the project.
Enter the title for the uninstaller as Windows should display it in its Add/Remove Programs control applet. You can use project variables here and Tarma QuickInstall will resolve them at build time. (See Uninstaller information for the details of what uninstallation information gets registered with Windows.)
Tip - The value of this field is available through the <UninstallTitle> project variable throughout the rest of the project.
Check this box to let Setup check for the presence of a previous version of your application and uninstall that before installing the current setup package; clear it to omit this check.
If you check this option, you should enter the uninstaller key for the previous version of your application. Setup uses this key to check if a previous version is present on the customer's system, and uses the uninstall information in that key to perform the uninstallation. By default, this key is set to <Uninstall>, i.e., the same uninstaller key as the one that you entered for the current version of the application in the Uninstaller key field above.
As of release 2.71, you can specify multiple previous version uninstaller keys by separating them with semicolons. At installation time, Setup will process each one in turn. If a particular uninstaller key is not present on the target system, it is silently ignored. The use of multiple previous version uninstaller keys is useful, for example, to uninstall multiple previous applications, or to uninstall an application whose uninstaller key has changed over time.
Tip - The value of this field is available through the <UninstallPrev> project variable throughout the rest of the project.
Note - During silent installs (see Setup command line options), Setup performs the uninstallation only if it detects that the previous version was installed with Tarma QuickInstall. In that case, it runs the previous version's uninstaller also in silent (unattended) mode. However, if the previous version used a third-party installer, Setup does not try to uninstall it when running in silent mode, but fails instead with exit code 14. The reason for this exception is that most uninstallers require user interaction, which is not desirable during a silent installation.
Check this box to query the customer for a previous version uninstallation; clear the box to perform the uninstall automatically without customer intervention.
Check this box to let Setup perform an aggressive cleanup during uninstallation; clear it to let it be more sociable. The difference between the two behaviors has to do with folder removal during uninstallation of your application. By default, Setup only removes folders that it specifically created; it does not remove pre-existing folders. By checking this option, Setup will try to remove all empty folders, even it they weren't created by Setup itself.
Note - Non-empty folders are never removed, not even when Clean up aggressively is checked. Therefore, it is relatively safe to use this option.
See After uninstallation, some (empty) folders are not removed. Why not? for more information.