Telerik blogs
InstallShield caused a lot of grief today by treating my code as inferior.  A single action worked differently if it was invoked by my code than if being called by an InstallShield "native" command. 

I was trying to implement some advanced logic in an installer's custom feature selection.  My goal was to have two features that you can install together or separately.  I wanted to force the user to install at least one of the features.  InstallShield does not support that, so I ventured into writing a custom action in JScript. 

I had a simple plan:
  1. Verify if both features are deselected and set a flag property.
  2. Enable or disable the Next button based on the flag's value.
Much to my surprise my code was being considered second class and the button did not get updated when the flag changed its value.  Property change notifications were not being fired.  Of course this is not the case when setting a property from the InstallShield GUI.  My workaround was to set the property to its current value in an additional action that was setup from the GUI and which runs right after my custom action.

You can do that by binding to an Event of a UI widget.  You will have two bindings: one for the DoAction call that runs your code, another for a SetProperty action.  SetProperty is an odd action, you don't call it by name.  You place the property name in brackets as the action name, and the value as the argument in the configuration grid.  In my case it looked something like:

Event Argument Condition
DoAction FeatureChoose_NextButtonEnable 1
[NEXTVALID] [NEXTVALID] 1


I hope the next poor soul that has to do something like that finds this post via Google.

Hristo Deshev is a Principal Software Engineer at Telerik
About the Author

Hristo Deshev

Hristo Deshev is a Principal Software Engineer at Telerik.

Comments

Comments are disabled in preview mode.