newObjects Active Local Pages - support area

last updated 28 May 2002

ALPInstall 1.1 notes

Version 1.1 of ALPInstall adds some new features and deals with much more situations automatically. the best way to review it in action is the ALPRedistApp.zip package which implements setup example - containing ALP and an application. To build your own you just need to put your application(s) in the package, change texts in the setup.cfg and modify paths and other settings where needed.

The new features:

  • Ask for destination paths
    See the section PATHS\ASKDESTINATION in the example. If you put there a section with a name matching one of the destination paths defined in the PATHS\DESTINATION setup will ask for it the first time package is installed. Section contains entries which define the texts on the displayed dialog.
    Notes:  If the user overwrites the package - e.g. installs again without uninstalling it before the new installation he will not be asked again for the destination path because it is already known from the first installation (setup saves it in the registry). This allows spreading of duplicate files to be avoided. Also if you are sending to your users new versions of your application frequently they do not need to remember where it was installed before.
    Note that user is asked for a path defined in the PATHS\DESTINATION therefore the variable has a default value. All the variables are used after asking the user thus if a destination path defined in PATHS\DESTINATION has a corresponding section in PATHS\ASKDESTINATION it will obtain the value selected by the user (or default one if the user decides to use the default value).
    Suggestions:  It is possible to ask for any number of paths you want but it is strongly recommended to ask for only one destination path. Practice shows that spreading the application to many locations causes unpredictable problems in future. This is true for any desktop application and  as you can see most of the biggest products on the market are asking for only one path. The reason is to keep all the application components in well known places because future extension of your product may need their integration.
    If you are bundling two or more independent (not relying on each other) applications in one setup package asking for a destination directory for every product could be reasonable. However packing them in separate setup packages will make them easier to support and update in the future and we recommend it.  
  • ALPRoot option in the sections responsible for content generators.
    For example section which installs alpaspcontext.dll contains ALPRoot setting set to the destination variable pointing to the directory containing the ALP default configuration files. This allows you to change the BasicAppLocation (in Main section) to point directory of your application (see the general comments below the list).
  • ALPInstBase.InstallSubdir class is improved.
    When installing directories (for example directory tree of your application) setup records all the files and directories installed and will not delete any files or directories created by the user or the application during its usage. 
    Notes: This allows your application to create some files which will not be deleted in its directory tree and if it is reinstalled (uninstalled and installed again) they will be preserved. In other words during the unininstallation setup deletes/uninstalls only the files installed during the installation and any files created later will not be deleted from the application directory tree.
  • Registry entries
    Registry entries can be installed by the setup. See the sample section FILES\REGISTRY. It contains two subsections:
    • INSTALL - contains the tree to be merged into the registry. Every subsection in it must be named with the full path in the registry where its contents will be written. Names of these sections must begin with a key name of the registry branch:
      HKLM - HKEY_LOCAL_MACHINE
      HKCU - HKEY_CURRENT_USER
      HKCR - HKEY_CLASSES_ROOT
      Their contents including subsections will be created/updated under the key defined by the name of the enveloping section. INSTALL section may contain as many sections as you need. Also note the (int)MapPaths=1 option in the INSTALL section (outside any subsections). If it is set to 1 all the string values in the sub sections will be patched and constants %XXX% will be replaced with the corresponding standard destination paths or the paths defined in the PATHS\DESTINATION.
    • UNINSTALL - Contains sections marking the registry keys to be deleted. Usually they are the sections listed in the INSTALL section but without any values in them - the entire keys are deleted. If you want a certain registry key to remain after the uninstall do not list it here. There is no need to put any subkeys in these sections because the entire keys are deleted. Be very careful to list the correct path of the keys to be deleted - better copy the sections from the INSTALL section and remove their contents.

    Suggestions: If you need to put some registry entries without resolving the %XXX% variables in their string values and some other entries need to be resolved separate them in two registry installation sections - for example create:
    { REGISTRY1: (ALPInstBase.InstallRegistry)
       { INSTALL:
          (int)MapPaths=1
       } INSTALL;
       ...
    } REGISTRY1;
    and
    { REGISTRY2: (ALPInstBase.InstallRegistry)
       { INSTALL:
          (int)MapPaths=0
       } INSTALL;
       ...
    } REGISTRY2;
    and put the entries in the appropriate sections.

  • More destination path constants are supported for the destination paths defined in the PATHS\DESTINATION section - here is the full list:
    TEMPDIR - Temporary directory
    PROGRAMFILES - Program files directory
    COMMONFILES - Common files directory
    WINDIR - Windows directory
    SYSDIR - System directory (system32 on NT/2k/XP or System on Win9X)
    STARTUP - StartUp folder in the start menu
    SENDTO - Send to folder
    TEMPLATES - Document templates directory
    DESKTOP - Desktop directory
    STARTMENU - Start menu directory (not recommended)
    STARTMENUPROGRAMS - Start Menu - Programs directory (not recommended)
    PERSONAL - Current user's personal folder
    FONTS - Fonts directory
    FAVORITES - Favorites directory (not recommended)
    Notes: Constants marked with (not recommended) are pointing to folders intended for shell shortcuts thus copying files there is not a good practice but can be useful in some very specific situations.
  • More paths are supported for the shell shortcuts
    Here is the full list:
    DESKTOP - Desktop
    START_PROGRAMS - Start menu - Programs
    SENDTO - Current user's "Send To"
    FAVORITES - Favorites
    STARTUP - Start menu - start up group
    STARTMENU - Start menu - do not place something here unless it will be used very often.
    TEMPLATES - Templates directory
    Notes: On Windows NT/XP/2k setup maps DESKTOP, START_PROGRAMS, STARTMENU and STARTUP to the common folders for the all users, on Win9X there is no guarantee they exist thus these constants are mapped to the user's profile. Note that StartUp, TEMPLATES exist for the current user only thus there is no way to place links in these locations for all the users on the workstation.
  • (int)PackageVersion option in MAIN section
    If not exists assumed to be 0. This allows you to mark the entire package with a version number (integer value). This instructs the setup to show reasonable warning messages in case of overwriting an existing installation. For example if you are updating your users with new version of your application increment it and they will see a message which recommends them to continue. If the user attempts to install an older package (with lower version number) message claims it is not recommended to continue.
  • (int)SuppressInitialQuestion option in MAIN section
    If exists and set to 1 suppresses the initial message "This will install ...".
  • (int)SilentReplace option in the MAIN section
    If set to 1 assumes "Yes to All" answer for all the overwrite file questions. Before setting it ensure it is safe to do so. Good for applications distributed to well known users if the application is to be updated frequently.
  • READMEDIALOGS subsection in MAIN section
    Defines dialogs displaying the contents of a text file to be shown during the setup. Define subsection for every dialog and specifay which file to be shown (path relative to the ALPInstall.exe - no mappings). See the comments in the sample setup.cfg. Pay attention to the:
    (int)NoCancel option which allows you to make the dialog informative only (set to 1) or able to cancel the installation (set to 0).
    (int)When option - Set to 0 shows the dialog in the beginning (after the initial question if any) or set to 1 shows the dialog after finishing the setup. These dialogs are always shown no matter if the installation overwrites existing installation. Therefore they are good place to set some notes for the users, place license agreements and so on.

General comments

In the sample BASEDEST variable is used as BasicAppLocation (see the main section). This directory is used by the setup to store the uninstall information and install/uninstall logs. When testing or solving problems consult these log files - in most cases any problem can be caught for a seconds by finding the error listed in the log.

Avoid changing the variables used by the ALP components. Better add more variables if you need to define more locations. Note ALPRoot option in the InstallCG sections. It points the directory where the default alp.site, alp.application and alp.directory files are copied. This is required by these components because they must be registered in these files - therefore if you change the ALP locations you will need to check if this option is still correct.

It is strongly recommended to leave ALP to install itself as it is defined in the sample file. If the user obtains another ALP application from another vendor it will try to update the ALP engine and keeping ALP engine in its standard location will prevent multiplication of the ALP files in many locations.

See the TESTPC directory included in the setup. It contain example ASP pages which test the system for the most commonly used MS ActiveX-es by the ASP pages. Read the comments in them and tune the pages for your application. Do not spend to much time to redesign them - they are shown only once (and only if component is missing or is older then specified) thus only the texts describing what to do are important. If you want to design an online page containing the updates on your site use the update.asp as an example. Or if you want to put these updates on the CD get them (see the comments in the page) and put them in a subdirectory of TESTPC and alter the paths in the update.asp to point them. What instructions to write there? Tell the user to install everything listed and if restart is required by one of the setups to select "no", install the resting files and then restart the system. Also if you want to provide files for non English OS versions - see on the MS site if they are available and put more links with appropriate description.

Back to ALP support site

Copyright 2001 newObjects