Custom action condition complexity

[oz1cz]

I need to create a number of software packages:

Package 1 consists of program X and data file f1.
Package 2 consists of program X and data file f2.
Package 3 consists of program X and data file f3.
etc.

As time goes by, additional packages may be added.

A user may install several packages, in which case program X is installed only once, but the respective data files are installed as needed.

When a package is uninstalled, it must check if it is the only installed package, and if that it the case, it uninstalls program X. But if one of the other packages is still installed, program X must be left in place.

I accomplish this thus: Each package considers X a prerequisite and installs it if needed. Then, each package creates an entry in the registry. Package 1 creates entry E1, package 2 creates entry E2, etc. When uninstalling a package, it checks for the presence of any of these registry entries, and if it finds none, it uninstalls program X. I do this in a custom action under InstallFinalize.

But as I don't know how many packages I may create in the future, I need to be on the safe side. Therefore my packages check for any of 12 possible registry entries.

In order to accomplish this, I need to create an execution condition under Custom Actions. The condition looks like this:

Code: Select all

(REMOVE="ALL") AND (NOT FEATURE_01) AND (NOT FEATURE_02) AND (NOT FEATURE_03) AND (NOT FEATURE_04) AND (NOT FEATURE_05) AND (NOT FEATURE_06) AND (NOT FEATURE_07) AND (NOT FEATURE_08) AND (NOT FEATURE_09) AND (NOT FEATURE_10) AND (NOT FEATURE_11) AND (NOT FEATURE_12) AND (NOT UPGRADINGPRODUCTCODE)

where, for example, FEATURE_05 searches for the E5 entry in the registry.

My first problem is this: This solution seems to me to be very clumsy. And if I ever create a 13th package, I'm in trouble. Is there a better way to do this?

My second problem is this: The above condition is 298 characters long. But Advanced Installer will not let me enter a condition that contains more that 256 characters. Using a text editor, I can edit the .aip file to contain the very long condition, but is that safe? (AI doesn't complain about finding a long condition in the .aip file)

Of course, I can replace "FEATURE_05" with "F5" to reduce the size of the string; but I guess my main worry is that there is some limit to the allowed complexity of the condition.
--
Claus

[Bogdan]

Hi Claus,

Then, each package creates an entry in the registry. Package 1 creates entry E1, package 2 creates entry E2, etc.

You could use a single registry value which stores the number of products that use program X. Each product installation can increase
the value and each product uninstall can decrease it (like a reference count). When the registry value is 0 (or 1, whichever you want for the start value),
you can uninstall program X. The registry entry can be easily handled through custom actions.

Another solution would for you to create a registry key under which each time you install another program that uses program X
it is added a new registry value. When a product will be uninstalled th corespondent registry value will be removed. This way when the last product that is
using the program X is uninstalled will remove the last registry value and therefore the registry key too.

All you have to do is to check for the registry key existence and use the result as a condition for the custom action that will uninstall program X.
This solution is not so recommend because it is a little bit error prone and might cause problems.

My second problem is this: The above condition is 298 characters long. But Advanced Installer will not let me enter a condition that contains more that 256 characters.

Here is what you could try for this:
---- you will split the condition into several smaller conditions like this:
-- create a custom action "Property set with Formatted" witch sets a public property to the value "TRUE"
-- this custom action will be conditioned by only half of the condition you use, for example:

Code: Select all

(REMOVE="ALL") AND (NOT FEATURE_01) AND (NOT FEATURE_02) AND (NOT FEATURE_03) AND (NOT FEATURE_04) AND (NOT FEATURE_05) AND (NOT FEATURE_06)

-- now you will add another custom action "Property Set with Formatted" that does the same thing for the second half (and off course sets another public property):

Code: Select all

(NOT FEATURE_07) AND (NOT FEATURE_08) AND (NOT FEATURE_09) AND (NOT FEATURE_10) AND (NOT FEATURE_11) AND (NOT FEATURE_12) AND (NOT UPGRADINGPRODUCTCODE)

-- now the custom action which used the original (too long) condition will have the following condition:

Code: Select all

PROPERTY_1 AND PROPERTY_2

-- assuming that PROPERTY_1 and PROPERTY_2 are the two public properties that you are setting with the above custom actions
-- as you can realize this method can be applied as many times as you wish

Please let me know if you have any questions.

Regards,
Bogdan

[oz1cz]

Hi Bogdan,

Thank you for your ideas.

Each product installation can increase the value and each product uninstall can decrease it (like a reference count).

Is that possible without using a script? I actually thought about this earlier, but according to this discussion, I need an external script to do that. So I was looking for a simpler way out.

when the last product that is using the program X is uninstalled will remove the last registry value and therefore the registry key too.

At what time during uninstallation is the registry key removed? How do I make sure the search criterion to be evaluated after the key has been removed?


--
Claus

[shelmers]

Claus,

Please see my post about incrementing a registry value in this related thread.

Scott

[Bogdan]

Hi Claus,

Is that possible without using a script? I actually thought about this earlier, but according to this discussion, I need an external script to do that. So I was looking for a simpler way out.

I'm afraid that using the script is the only solution. Please try this approach and if you encounter any problems let us know.

At what time during uninstallation is the registry key removed? How do I make sure the search criterion to be evaluated after the key has been removed?

The registry key is removed during the standard action "RemoveRegistryValues".

Please note that the search should also be implemented into the script of your custom action. You will not use the Search page of Advanced Installer for this search.
This way you can schedule the custom action under the InstallFinalize phase without any problems.

Let me know if you have other questions.

Regards,
Bogdan