The Update page allows you to control your installer's behavior in case (a previous version of) the same application is already installed.
The "prevent installation while there is an open window with this class name" allows you to specify the window class used by your application's main window. The installer will prompt the user to close your application if it detects an open top-level window with this class name. You can specify multiple window class names by delimiting them with semicolons.
The "prevent installation while there is an open window with this caption" allows you to specify the text shown on the caption of your application's main window. The installer will prompt the user to close your application if it detects an open top-level window with this text as its caption. You have to specify the entire caption. You won't be able to use this method if your application puts dynamic information in its caption such as the name of the file the user is working on. You can specify multiple captions by delimiting them with semicolons.
If you specify both class names and captions, the installer will prompt the user to close your application as long as there is at least one window that has either one of the window classes you specified, or has one of the captions you specified, or both.
If you always put all files that your software consists of into every installation package, then DeployMaster will intelligently update the user's computer when a newer version of your software is installed on top of an older version. You can control whether a particular file should be overwritten or not on the Files page.
The options on the Update page allow you to create installation packages that contain only files that were updated since a certain previous release of your software. Such installation packages are also called "patches".
If the installation package contains all files that your software consists of, you can turn on the first option. When you do so, and version 2.0 of your software lacks certain files that were included with version 1.0, DeployMaster will delete those files, keeping the user's computer nice and clean. Obviously, you have to turn off this option if you want to create a "patch" installer.
The user should only be able to install a patch on top of a version of your software that your patch supports. E.g. a patch for 2.0.3 can update versions 2.0.0, 2.0.1 and 2.0.2, but not older 1.x.x releases. DeployMaster can check this requirement.
DeployMaster uses the application release date that you specify on the Project page to differentiate between versions of your software. In our example, you need to specify the release date of version 2.0.0 as the "required version" on the Update page. DeployMaster will check if the currently installed version of your software has an application release date equal to or more recent than the "required version" date on the Update page. If so, the user can install the patch as usual. If not, the installation buttons will be disabled, and the text you enter on the Update page will be displayed. You can enter up to three lines of text, explaining the requirements of the patch to the user, in terms the user will understand. I.e. you should mention the base version of the software required, and where the user can obtain it.
Remember that DeployMaster differentiates between different applications using the application name that you specify on the Project page. This means that a patch must have the same application name as the base installation that it patches, which obviously also must have been deployed with DeployMaster. This also means that if you concurrently maintain different version lines, both version lines will need different application names. E.g. if it is possible that you will release a version 1.x.x after 2.0.0 has already been released, then you need different application names for both to make sure that the 2.0.3 patch does not consider the latest 1.x.x as a valid base for patching.
Finally, you need to add the files that should be distributed with the patch on the Files page. One way is to open the .deploy file for the full installation package, delete the files that should not be part of the patch from the Files page, and save as a new .deploy file. Another option is to use the .deploy file of the full installation package, and instruct DeployMaster to only include files that were modified after a certain date in the patch. You can do that on the Update page. When you click the Build button, DeployMaster will indicate in the build's progress which files were skipped because they were not modified since the given date. If any skipped files are used as the target for shortcuts and file types, those will be excluded from the patch as well. Though DeployMaster will warn about this, there is no problem as the base installation should already have created those shortcuts and file types.