6 replies to this topic

[JoeThompson]

If I have an installation with 6 Features and the user goes to the Custom Setup dialog and selects 3 of them to install, how do I only show the dialogs in my UI sequence that pertain to the selected features.  For example, if one of the features installs an LDAP client and the user does not select it, I don't want to show him a dialog asking for the LDAP password, etc.

Thank you,
Joe

[BobRouse]

Use the GetFeatureState() function, eg:

MsiGetFeatureState(hInstall, "LDAP", nvState, nvAction);
if nvAction > 2 || (nvState > 2 && nvAction = 2) then
   // Setting global flag for later use. Could also put code here...
   bLDAPInstall = TRUE;
endif;

[Scott Mayham]

I have had a similar situation in the past, and have been successful applying a condition on the dialog box, based on the Install state of the feature, for example:

   &Feature > 2

I also use this to condition the Back button of the dialog which follows, so that the user can't "back" into a dialog box which makes no sense.

However, I've seen it stated on this forum (I think) that one needs to re-call CostFinalize after CustomSetup in order to assure the correct setting of the Install states of the sellected feature(s).  I've not done that, and have not yet encountered problems.  

Stefan, good fellow, perhaps you can shed lome light on this issue.

regards,

[Stefan Krueger]

This would only be the case for feature conditions because they are only evaluated during CostFinlaize. But you should not call CostFinalize more than once.
If you want to change the feature selection after CostFinalize you can use control events like AddLocal and Remove, or call SetInstallLevel

[Scott Mayham]

Well, I'm having a little difficulty understanding the logic behind this sequence.  If understand what you are saying, the sequence goes something like this:

1. The CostFinalize stuff is done, and the feature states are evaluated and set.
2. The SetupType and (possibly) the CustomSetup dialogs are run.  I'm most concerned about CustomSetup, because as a consequence of that dialog, the selection of features will almost certainly change.
3. Some sort of machinations are needed to bring the Install states up to date with the choices made in the CustomSetup dialog.

Doesn't that sound strange?  The purpose of CustomSetup is to change the complement of selected features.  Are you saying that the install state properties of the features are not updated automagically to reflect the selection in CustomSetup?  What good are they then, if they cannot be "trusted" in any situation other than a "Complete" installation?  

I must conclude that I don't understand their purpose, or your comments, or both.

Regards,

[Stefan Krueger]

When I say "feature condition" I mean a condition that is placed on a feature. If the condition is true, the InstallLevel of this feature will be changed to the specified level. I don't mean conditions that are based on feature selection states, like &FeatureName=3, that you put on a custom action for instance or to control which dialogs will be displayed.
Feature conditions are evaluated during CostFinalize. This makes a default selection of features, or can even hide a feature that doesn't apply to the operating system or something.
Later the CustomSetup dialog can change the feature selection. CostFinalize is not required to make these selections take effect. The dialog directly changes the features' selection state.
The install states of the features are automatically updated by the CustomSetup dialog and can be used without re-running CostFinalize.

[Scott Mayham]

Thanks, Stefan, for the clarification.  I can see now that I had two different concepts muddled together.  I'm also greatly relieved to see that despite the muddle, my several installations will continue to work as intended.

Regards,