Persistent INI file entries

[Fig]

My install deploys a .INI file that is marked (Never Overwrite) so an upgrade or re-install will not overwrite it.

I want to add several entries to this INI file on the *first* install only, and a few others whenever a repair, modify, or initial install runs. I also want the entries to remain persistent (not be uninstalled). How might this be accomplished?

If I do:
Edit INI File $TARGETDIR$\\app.ini, [Config] CheckUpdate=1
Apply Install
... errors indicate the app.ini cannot be written. Error Code 2110.

If I do:
Edit INI File $SUPPORTDIR$\\app.ini, [Config] CheckUpdate=1
Apply Install
... errors indicate the app.ini cannot be written. Error 2110.

If I do:
Apply Install
Edit INI File $TARGETDIR$\\app.ini, [Config] CheckUpdate=1
... the changes do not get written to the file.

[MichaelNesmith]

The error code, according to the Windows SDK, is:

Key missing for .ini action.

Adding a command after Apply Install will not have any effect - this is normal behavior (please read the help topic titled "Setup Commands Preceding Apply Uninstall" for details).

If you wish to persist changes to an INI file, this is not really possible with Windows Installer. It will always roll back your changes when you uninstall. What you can do is use the Write to Text File (and Read from Text File) commands to directly update the INI file, when you wish. These commands are not subject to the Apply Install limitations discussed above, they are like Windows Installer custom actions which execute immediately.

About first install/repair-modify distinctions, this can be made by reading the value of the MAINTENANCE variable, which is FALSE when a first time install is running. You can also use the Get INI File Settings command to obtain existing values in an INI file.

Hope these help!

[Fig]

I appreciate the quick response!

The 2110 code error makes sense now. I was attempting to use the Edit INI File command to remove an entire [Section] of my app.ini file ... that is with no key and no values:

Edit INI File $TARGETDIR$\\app.ini, [Updates] =

The WinSDK WritePrivateProfileString() function allows NULLs for the Key and Values to wipe out an entire section. Instead, I will create a line in my script for each 'key' in the Section and use Line->Remove for each.

Suggestion: IA should consider modifying the help file. Under Edit INI File the "Action" item says:
"Choose the desired editing action from the drop down list."

I cannot find description for these action items. I could guess at the "Line" actions but am unfamiliar with Tag->Remove or Tag->Add.

[Fig]

I moved my persistent app.ini stuff into a .DLL that gets called after the "Apply Install" command. It works on the Initial install but something odd happens when I do a subsequent Maintenance install (select Modify).

Set Variable VAL1 to
Set Variable VAL2 to
Set Variable VAL3 to
Display Dialog: registration, wait for dialog to return (modal) // runs in both Initial and Modify wizard loops

Apply Install (get result into variable SUCCESS)
If SUCCESS Equals COMPLETE
Call DLL Function $TARGETDIR$\\mydll.dll->ChangeIni
end

where mydll.dll has ChangeIni prototyped as:

Code: Select all

extern "C" {__declspec(dllexport) int WINAPI ChangeIni (long lVal1, long lVal2, LPSTR pVal3);}

(e.g. pass in 2 long values and a pointer to a string). The values come from user input in the "registration" dialog.

This works great for the *initial* install. All the values are written to the app.ini file as expected.

However, when I run the install again and select MODIFY, any of the *changed* long values are passed into my .dll with values of 0. The string VAL3 is always passed correctly. When debugging I see that VAL1 and VAL2 are set to new values I've specified in the 'registration' dialog just before calling the DLL, but once in the DLL they are zero. When the DLL returns they become zero in the script, too.

If it were a string conversion issue I would suspect it wouldn't work on the initial install. BTW, I am using masked edit controls in "registration" to specify numerics for VAL1 and VAL2.

Is there some different behavior I'm missing between the initial install (MAINTENANCE = FALSE) and the modify install (MODIFY=TRUE)?

[MichaelNesmith]

I'd double check that all parameter types are specified correctly in the script. Also remember to correctly dereference variables if they are being used. The behavior should definitely not change between the installation modes - as far as the setup engine is concerned, that does not matter.

[Fig]

How does one specify a variable 'type' in the script?

Nothing changes between one call to the DLL and the next. It uses the same script, but it works for an Initial install but not a Modify install. Perhaps it is just a fluke that it works on the Initial install.

[MichaelNesmith]

You do not specify the type in the script, but in the Call DLL Function, which converts types for you.

If you specify a string value where Call DLL expects an integer, or a space/etc. after the integer, that might explain the "0" coming in.

[Fig]

The DLL parameters are correct.

The variables come from the 'registration' dialog.

Just before the call to my DLL the variables have the correct values. At the first chance inside the DLL I check the values (e.g. via a MessageBox() call).

On the Initial install they are correct in the script before the call, within the DLL, and upon return from the DLL.

On Modify installs they are correct before the call, but are incorrect (= 0) within the DLL and incorrect upon return from the DLL.

It just doesn't make sense that it would work on the initial install but not on maintenance installs. Is there something that might lock the value or prevent a change from occurring?

[Fig]

I forgot to mention ...

The weird thing is that when I run a maintenance instal, but do not change the parameters in the registration dialog (they are read into the variables from the exisitng INI file beofre 'registration' is called) the variables are correct in the script before the call, within the DLL, and upon return from the DLL!

In other words, during a MODIFY maintenance install, if I do not change the parameters in the 'registration' dialog my DLL gets the correct parameter values.

[MichaelNesmith]

That's very strange.

Did you make sure to declare the variables used in your dialog before the dialog is called?

I'm sure its something simple, we should figure it out soon.

[Fig]

The variables are declared before the dialog is called.

The regions and variable related stuff looks (pseudo)like:

Code: Select all

DEFINE REGION: Define Setup Globals
Set Variable VAL1 to
Set Variable VAL2 to
Set Variable VAL3 to
Get INI ... into Variable VAL1
Get INI ... into Variable VAL2
Get INI ... into Variable VAL3
END REGION

DEFINE REGION: Setup User Interview
// ... Initial Install
Display Dialog: registration, wait for dialog to return (modal)

//... Maintenance install
Display Dialog: registration, wait for dialog to return (modal)
END REGION

DEFINE REGION: Process (Un)Install
DEFINE REGION: Perform Uninstallation
// blah blah blah
END REGION

DEFINE REGION: Perform First Time or Maint Installation
Apply Install
Call DLL ...
END REGION
END REGION


So, declare the vars, then fetch them from an existing INI file so they can populate entries in the 'registration' dialog. Later, after the installation is applied, my DLL is called with the changed vars.

I agree. This must be something simple. I just can't see it yet.

[Fig]

Problem solved. I don't believe I adequately understood how the IA script variables hold type.

My 'registration' dialog used masked-edit controls with some masks specifying numeric input. The input was saved to script variables.

When I passed them in as type 'long' to my custom .dll on the initial install it worked fine, but wouldn't work on subsequent modify installs.

I changed my .dll to accept them as type 'pointer to string' (converting them in the custom .dll to 'long') and now it works on both initial and modify install.

I still do not understand why this worked on the initial install, but at least my script is working now.