Multiple Installs - Messaging and Start-Menu subfolders

Hi All -

Currently our installer, if you attempt to install to the same location that the application already is installer to the NEXT button is greyed out on the the "Choose Install Location" page. If you change the directory the NEXT button is available. Working as intended.

The ask from QA is to have some sort of message pop up to indicate that this is why the button is greyed out. This is what I have now, adding in the message box:

Function .onVerifyInstDir

        InstallHash::hash $INSTDIR

        Pop $Sha1hash

        

        ReadRegStr $VerifyInstallDirectory HKCU "Software\{#ProjectInternalName}_$Sha1hash" ""

        

        ;no duplicate installation paths

    	  StrCmp $INSTDIR $VerifyInstallDirectory 0 PathGood1

    	  ; MessageBox MB_OK|MB_TOPMOST|MB_SETFOREGROUND|MB_ICONSTOP "An installation already exists at '$INSTDIR'.  Please select another directory."

        MessageBox MB_OK|MB_TOPMOST|MB_SETFOREGROUND|MB_ICONSTOP "An installation already exists at '$INSTDIR'.  Please select another directory."

        Abort

        PathGood1:

		    

        ; no double back slashes

        ${WordFind} "$INSTDIR" "\\" "*" $R0

        StrCmp $R0 "$INSTDIR" PathGood3 0

        ;MessageBox MB_OK|MB_TOPMOST|MB_SETFOREGROUND|MB_ICONSTOP "double backslash"

        Abort

        Pathgood3:

		    

    FunctionEnd:

But what is happening is on the page prior, Region select, once I select NEXT the message pops up before moving to the Install page - and then it pops up again once the Install page loads.

I am not sure what the best answer is here. Looking for suggestions. Is there a way to put a tooltip on the greyed out button only?

Thanks for any and all help/suggestions.

Ginn

It is hard to provide a label that you can show/hide/change because .onVerifyInstDir is not called for all invalid paths.

A alternative is to allow the next button to stay enabled and perform this check in the directory page leave callback...

Thanks Anders, I will give that a try and see if it gives them what they want.

Multiple Installations - Start Menu Shortcuts

The last suggestions worked perfectly so I figured I would come back for more.

Our installer currently is setup for multiple installations. We do this by generating a HASH that we use when we are setting up the registry information. This allows us to differentiate the multiple installations. Works great. However the "Powers that Be" do not like how we setup the Start Menu Shortcuts.

This is basically how we set up the directory structure for our Start Menu Shortcuts:

ApplicationName Dir

   HASH Dir

      Uninstaller.exe

      Installer.exe

We would like to be able to replace the HASH with the directory name the user actually used when installing the Application. If the user used the default C:\Program Files\Foo :

ApplicationName Dir

   Foo

      Uninstaller.exe

      Installer.exe

And if the user changed the default install location from C:\Program Files\Foo to C:\Program Files\Bar, the idea would be to use "Bar" in our structure. So you end up with this:

ApplicationName Dir

   Bar

      Uninstaller.exe

      Installer.exe

I am just unsure where that information is captured and if it is usable. I hope that explanation makes sense. It does in my head. As always I appreciate any and all help!

Thanks!

Ginn

You are not supposed to create a shortcut to the uninstaller, this has been in the MS guidelines for at least 15 years.

In a Win8 world it makes most sense to just create a single shortcut at the root of $SMPrograms. If the thing you are installing is a suite of several applications (like MS Office) you could use a subfolder but for most things a single shortcut is the best option.

Using parts of the installation path as the start menu folder name is crazy. The usual conventions are "Appname\version", "Company\Appname" or "Appname" for subfolders or if you are installing a game you can read the name of the Games subfolder from the SM_GamesName value in the registry. Your Win8+ users will thank you if you can narrow it down to just a single shortcut in the programs root...

I appreciate the response Anders, as always. Noted about the uninstaller shortcut. I had taken over our installer tech a little bit ago due to the person running it is no longer with the company, so I am learning all the ins and outs.

With our product there are users who do install the application multiple times, the same version. Our first attempt was to put the shortcuts in "CompanyName\AppName", but if you install the same application to a different directory it will overwrite the shortcuts of the previous install since it is using just the "CompanyName\AppName" as it location.

The solution that the previous engineer came up with was to put a subdirectory under "AppName" called "HASH" and this was generated during the installation, so you get "CompanyName\AppName\HASH". And it worked fine. But the "Higher Ups" did not like how it looked, so now we need to find another solution. So I need to be able to have the ability to have a user install the same application to different directories, but in the start menu be able to differentiate from previous installations. So I would have "CompanyName\AppName\Foo\.exe" and "CompanyName\AppName\Bar\.exe". But the directory needs to make sense and that is where I am stumbling. Someone had suggested to me to just use the directory where the user installs to. But if that is not a good practice I do not want to implement that.

Again, I appreciate any assistance you offer. You have been a big help in learning this system and being able to apply fixes.

Thanks!
Ginn

Well, if you have to do this then I guess you could use the folder name but that does not stop someone from installing to "c:\abc\foo" and "c:\def\foo".

If these are actually separate versions then why not just name them "MyApp 4.lnk" etc? If they are the same major version then it really makes little sense to allow multiple installs.


The way MSI handles this is that a "all users"/machine install places the shortcuts in the shared start-menu folder ("SetShellVarContext all" in NSIS for $SMPrograms) and a "single user"/"Just Me" install uses the per-user start-menu folder. The start menu will then contain the per-user shortcut if it is installed, otherwise it contains the machine shortcut. This means MSI only supports two side by side installs of a major product version. I'm not saying you should go down this route because it is hard to pull off correctly. I just wanted to provide some extra context.


See also: http://msdn.microsoft.com/en-us/libr...=vs.85).aspx#:

Don't create a product folder if your suite contains only a single shortcut. Place your shortcut in the top-level Start folder