cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
donnie1
Level 3

DATABASEDIR Changed in Custom Action

I have searched the threads, and I see a number of very similar issues...some dating back to 2004! I can't believe that 7+ years have passed without resolution, or at least a solid workaround, so I am going to post again.

SCENARIO:

Basic MSI. After Database Folder dialog, a VBScript Custom Action that verifies the selected directory is NOT a private folder. If it is, VBScript custom action changes Session.Property("DATABASEDIR") back to the default location, and displays a friendly dialog explaining the reasoning.

PROBLEM:

Though the session property is changed successfully (it reflects correctly if the "BACK" button is used to display the Database Folder Dialog again), the folders/files destined for this directory are installed in the location originally selected (that is incompatible with the needs of our application). In fact, sometimes, SOME of the files/folders are installed in one location, and SOME are installed in the other! :mad:

QUESTIONS:

Is there an update or some other method that I need to call after changing the session property but before installation continues? How can I accomplish my goal here within the seemingly robust InstallShield Express model?

I am frustrated, because I don't want to kill the installation process if the user selects an invalid location. I don't want to script something that runs after the installation to move files/folders from this unacceptable location to a common area.

Please someone share with me what I am doing (or NOT doing) properly. Any advice or suggestion is greatly appreciated.

:confused:
Labels (1)
0 Kudos

(1) Reply
donnie1
Level 3

I searched these forums extensively for an answer to a seemingly simple issue, but to no avail. As stated above, I found this issue going back a number of years, but never saw any advice on how to resolve or work around it.

For those new to InstallShield who come after me seeking a solution to the same problem, I am including the steps below.

This solution applies to the following installer configuration:

1) DATABASEDIR set initially to [CommonAppDataFolder], but allow user to change.
2) Destination Computer's file system set to have a directory created in DATABASEDIR with subfolders of it's own (i.e [DATABASEDIR]\SingleSubfolder\ManySubFolders)
3) Custom Action (VBScript) runs AFTER Database Folder dialog that validates criteria regarding the selected Database Folder Path and reverts to default location accordingly. (In my case, I make sure the user did NOT select a personal folder...if they did I return Session.Property("DATABASEDIR") to the default location [CommonAppDataFolder])

The problem here is that the expected behavior (I would think) is that any subdirectory configured UNDER the DATABASEDIR would change as well, whenever the DATABASEDIR property is changed, but that is NOT how InstallShield handles it. How does InstallShield handle it?

Installshield creates a session variable for each directory targeted for the destination computer (i.e. a folder in the subdirectory named Folder1 might have a variable like Session.Property("FOLDER1") ). When Session.Property("DATABASEDIR") is altered programatically, the variables holding the path for the subfolders remain intact.

SOLUTION: In the custom action that runs after the Database Folder Dialog, I change each variable manually, as it relates to the root.

EXAMPLE:

Const USER_PROFILE = &H28&
Const COMMON_APP_DATA = &H23&

Set objShell = CreateObject("Shell.Application")

Set objProfile = objShell.Namespace(USER_PROFILE)

Set objProfileItem = objProfile.Self

Set objCommon = objShell.NameSpace(COMMON_APP_DATA)
Set objCommonItem = objCommon.Self

If InStr(Session.Property("DATABASEDIR"), objProfileItem.Path) > 0 Then
Session.Property("DATABASEDIR") = objCommonItem.Path & "\"
MsgBox "The working folder selected is a private directory, specific to the active Windows user account." & chr(13) & chr(13) & Session.Property("ProductName") & " requires a PUBLIC working folder, so InstallShield has changed your selection back to the default location." & chr(13) & chr(13) & "If you must change this location, select a public directory, or cancel installation until such location is available.", 48, "Invalid Folder Selection"
End If

Session.Property("SINGLESUBFOLDER") = Session.Property("DATABASEDIR") & "SingleSubfolder\"
Session.Property("MANYSUBFOLDERS1") = Session.Property("SINGLESUBFOLDER") & "ManySubFolders1\"
Session.Property("MANYSUBFOLDERS2") = Session.Property("SINGLESUBFOLDER") & "ManySubFolders2\"
Session.Property("MANYSUBFOLDERS3") = Session.Property("SINGLESUBFOLDER") & "ManySubFolders3\"
Session.Property("MANYSUBFOLDERS4") = Session.Property("SINGLESUBFOLDER") & "ManySubFolders4\"
Session.Property("MANYSUBFOLDERS5") = Session.Property("SINGLESUBFOLDER") & "ManySubFolders5\"

This admittedly is quite the hack, but I have yet to find a better way to preserve the relative values of these subdirectories.

I discovered these individual variables only by sifting through the MSI log files. I can't think of a single reason why a developer would INTENTIONALLY create a folder structure in the visual designer, and then want to NOT maintain it (at least not by DEFAULT) if the user changes the root path...so in my opinion this is a defect in the product. Judging by the length of time that has passed since this was originally discussed on this forum, I call it a defect that has been largely ignored by InstallShield, and vastly under-documented. If this behavior is by design, I submit that it a FLAWED design and should be reconsidered. In fact, I should like to hear the reasoning behind this engineering failure.

As a paying customer, I would like to see this issue resolved in future releases of the InstallShield product. It has personally cost me several hours of research, diluted the productivity of myself and some on my team, and likely postponed our initial product release, while we thoroughly test this hack on numerous platforms and environments.

I hope someone finds this information useful.
0 Kudos