l_d_allan
12th October 2005 14:39 UTC

InstallDirRegKey work with (^Name)?

Name "My Project"
... some statements ...
InstallDir "$PROGRAMFILES\Project Family\$(^Name)"
InstallDirRegKey HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$(^Name)" "Install_Dir"
.... more statements ...
WriteRegStr HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$(^Name)" Install_Dir $INSTDIR

InstallDir can resolve (do variable/macro replacement of) $(^Name), as can WriteRegStr, but it doesn't seem like InstallDirRegKey can do this. If the end-user changes the Installation directory from:
C:\Program Files\Project Family\My Project
to
C:\Temp\AlternateName
then the next installation uses
C:\Program Files\Project Family\My Project

InstallDirRegKey works ok if I don't use $(^Name):

InstallDirRegKey HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\My Project" "Install_Dir"

Am I doing something wrong or leaving something out? Should I be using an actual variable rather than a "pseudo variable" like Name?

I'm helping a freeware project convert from InstallShield to NSIS, and I believe the original script was generated by the Eclipse plug-in, using the Modern UI.

kichik
12th October 2005 14:45 UTC

InstallDirRegKey can not use language strings or variables because it's read before the language tables are initialized. It should say that in the documentation, I'll add it.

l_d_allan
12th October 2005 14:57 UTC

Thanks ... you're good!

I have always been incredibly impressed by the support made available on this forum. Oh, that other software was anywhere near as good.

InstallDirRegKey can not use language strings or variables because it's read before the language tables are initialized.

Having said that, is there a technical reason why InstallDirRegKey can't resolve variables, and has to be read before the language tables are initialized? It seems like pretty much everything else can.

If not, perhaps this statement should be forced to be very close to the top as a "clue" that it has to be treated differently?

I was going to look around in the NSIS code to see how the "Check for Update" code worked (to clone into my own project code). Perhaps you (or someone else) could point me where to look, and this behavior could be revised, as applicable. (Just trying to help ... :-)

kichik
12th October 2005 15:06 UTC

There's no technical reason, only a functional one. InstallDirRegKey is processed before .onInit, so .onInit will be able to check $INSTDIR and manipulate it, if needed. The language table is fully selected only after .onInit, and the earliest place variables can be initialized is .onInit.

Check for update is implemented in Contrib\MakeNSISw\update.cpp. The server backend code is attached.

l_d_allan
12th October 2005 15:50 UTC

Thanks very much for the link to the "Check for Update" code.

!define PROJECT_FAMILY "The Family"
!define PROJECT_NAME "The Project"
Name "${PROJECT_NAME}"
; ... some statements ...
InstallDir "$PROGRAMFILES\Project Family\${PROJECT_FAMILY}\${PROJECT_NAME}"
InstallDirRegKey HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\${PROJECT_FAMILY}\${PROJECT_NAME}" "InstallLocation"
; ... some more statements ...
WriteRegStr HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\${PROJECT_FAMILY}\${PROJECT_NAME}" InstallLocation $INSTDIR

The above seems to work ok (preview shows space before " SOFTWARE" which isn't there). My preference is to have one statement to change, and minimize the proliferation of the same information all over the script. Does this seem like a reasonable "work-around", or are there flaws I'm naively overlooking?

The norm in the uninstall "sub-hive" seems to be only one level (${PROJECT_NAME}) rather than multiple levels (${PROJECT_FAMILY}\${PROJECT_NAME}). At least with WinXp, the Add/Remove programs seems to work ok, and reinstallations seem to recognize and use ${PROJECT_FAMILY}\${PROJECT_NAME}.

BTW: I came across the link:
http://cvs.sourceforge.net/viewcvs.p....html?rev=1.56

which seems to indicate that InstallLocation in the Uninstall "sub-hive" is the preferred place for this information. Seem reasonable?

kichik
12th October 2005 16:08 UTC

A define is OK and it's actually the common way of doing this. It's also a liter solution because it involves no runtime code at all.

InstallLocation under a subkey in the Software\Microsoft\Windows\CurrentVeresion\Uninstall is not only the preferred location, but the only possible location as far as I know. The Add/Remove control panel doesn't look in sub-subkeys to the best of my knowledge.