Update vs install re-visited

[Edgar Prothero]

Hi again,

I am sorry that I did not make myself clear or understood.  I guess I WANT there to be a difference between the two options I previously mentioned.  You see, my program exports the settings that an existing user has created upon UPDATE and installs the default settings with a fresh install.  I have ALREADY CODED AND TESTED the settings part.  It works great with no issues.  What I would like to accomplish is to have INNO determine if this is a fresh install or an update and run the utility I created to get the settings.  I only want this to happen then and not during a fresh install.

It would also be nice to have the user SEE that it (INNO) is only going to update vs re-install the program.  

Please advise

Ed Prothero

Michigan

[Robert van der Hulst]

Ed,

You should be able to use the GetPreviousData() /SetPreviousData() functions in your code section to see if the product is already installed.

Based on that, you should be able to enable/disable certain options.

Op dinsdag 21 mei 2024 om 16:11:40 UTC+2 schreef Edgar Prothero:

[Gavin Lambert]

On Wednesday, May 22, 2024 at 2:11:40 AM UTC+12 Edgar Prothero wrote:

I am sorry that I did not make myself clear or understood.  I guess I WANT there to be a difference between the two options I previously mentioned.  You see, my program exports the settings that an existing user has created upon UPDATE and installs the default settings with a fresh install.  I have ALREADY CODED AND TESTED the settings part.  It works great with no issues.  What I would like to accomplish is to have INNO determine if this is a fresh install or an update and run the utility I created to get the settings.  I only want this to happen then and not during a fresh install.

The previous response that you received on this topic was correct, though: if you do that, you are doing it wrong -- your program has a bug.  You should fix that bug instead of ploughing ahead anyway.  While it may appear to work for some users, that just means that your testing is incomplete and you and your users will run into trouble eventually.

In a PrivilegesRequired=admin installation (the standard and recommended approach), the installer itself should only install per-machine things (e.g. HKLM or {pf}).  Meanwhile your application does not run with admin privileges and while it can read per-machine settings it cannot write them.  So while you can save some defaults at install time, the actual active settings must be stored per-user (e.g. HKCU or AppData).  This is especially true because the installer is run only once, but the app might be run by either multiple users or just a different user than who installed it (think of a business machine where an IT admin installs it, but that's not the day-to-day user of the app).  It might not even be possible for the installer to access the per-user settings of the day-to-day user (nor should you try).

The installer can install and upgrade those per-machine defaults, but any installation or upgrade of the actual per-user settings must be left to the application itself, and may need to happen more than once (as different users run the new version for the first time).

For upgrading those default per-machine settings, it's usually sufficient to use flags to avoid overwriting existing files/values, but you can do something more complex if you wish.  Usually the trigger to detect that is simply that they already exist, possibly with some app-specific check to determine that they're outdated in some way.

You can relax some of this by making a per-user installation instead of a per-machine one, but this is not recommended for most apps -- it limits what things can be installed (and where), wastes disk space if the app is needed by multiple users, and bypasses some security rules that IT admins like having around.