This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Altering INSTALLSTATE from user interface
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 10, 2010
11:37 PM
Altering INSTALLSTATE from user interface
I have placed a number of conditions against different features. These conditions change the installevel of the feature.
The conditions are determined by the values of properties that are set by checkboxes during the UI of the installation. The problem is the fact that the CostFinalise routine runs before the user interface is even launched. So right now the conditions always run with the properties default value as this is what the properties values are before the user interface is triggered.
I am wanting to do something I thought would have been simple, it still maybe and I may just be missing something. But instead of showing the user a very complicated feature selection screen I wanted them to select 1 of 5 checkboxes. Different combinations of boxes determine which different features should be selected.
Can someone please advise how I may do this. Ultimately I do not wish to run a script and thought I would be able to find a way of changing the feature status after the user interface had been launched other than using the CustomSetup dialog.
Any thoughts or suggestions would be welcome.
The conditions are determined by the values of properties that are set by checkboxes during the UI of the installation. The problem is the fact that the CostFinalise routine runs before the user interface is even launched. So right now the conditions always run with the properties default value as this is what the properties values are before the user interface is triggered.
I am wanting to do something I thought would have been simple, it still maybe and I may just be missing something. But instead of showing the user a very complicated feature selection screen I wanted them to select 1 of 5 checkboxes. Different combinations of boxes determine which different features should be selected.
Can someone please advise how I may do this. Ultimately I do not wish to run a script and thought I would be able to find a way of changing the feature status after the user interface had been launched other than using the CustomSetup dialog.
Any thoughts or suggestions would be welcome.
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 11, 2010
05:58 PM
It sounds as if the Remove and AddLocal control events might be of use.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 11, 2010
06:14 PM
Alot of use. Many thanks I knew I had overlooked something.
That should work perfectly. Again much appreciated.
That should work perfectly. Again much appreciated.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 14, 2010
10:50 PM
Any chance you could suggest what I am doing wrong ?
I have used the "Remove" Control event from the Next button on the license dialog to set all Features not to install by default. So if just those are left nothing should be installed.
On the Next button on the ReadyToInstall dialog I place AddLocal control events to only install the feature/s given a condition built from a number of properies the user sets during the installation.
I did a dump of the install and all the property values were set correctly.
But what happens is that ALL features are installed, not just those that should have had the AddLocal control event run from the ReadyToInstall dialog.
All I am wanting to do is turn off features depedant upon some property values set by the user during the UI. Was pretty confident this was the way to do it after the advice I was provided above.:confused:
I have used the "Remove" Control event from the Next button on the license dialog to set all Features not to install by default. So if just those are left nothing should be installed.
On the Next button on the ReadyToInstall dialog I place AddLocal control events to only install the feature/s given a condition built from a number of properies the user sets during the installation.
I did a dump of the install and all the property values were set correctly.
But what happens is that ALL features are installed, not just those that should have had the AddLocal control event run from the ReadyToInstall dialog.
All I am wanting to do is turn off features depedant upon some property values set by the user during the UI. Was pretty confident this was the way to do it after the advice I was provided above.:confused:
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 14, 2010
10:58 PM
Hi Swilks,
Changing the request state of a feature is a messy business. From my own experience, some things to be careful of:
--The ControlEvent to fire last wins. So, in your example if all requests get made as Remove = All, then some AddLocal events fire, reasonably you would expect only the AddLocal'd features to be selected.
--However, if you've got the ADDLOCAL property set, this is going to also have an effect on selections (and this trumps previous 'Remove' ControlEvents).
--Similarly, REMOVE being set has an effect.
--If this is a Major Upgrade, potentially you might end up with MigrateFeatureStates interfering.
--Lastly, if this is an InstallScript MSI, keep in mind that feature selections get passed in the form of ADDLOCAL based on dialog input. This doesn't sound like it's the case, though, since ControlEvents are in the equation, but it's a 'Gotcha'.
--I don't recall offhand if this trumps ControlEvents or ADDLOCAL, REMOVE, but try double checking to see if any are marked as 'Required'.
If all else fails, you might just post your *.ism and install log and it might provide the answer.
--Cary
Changing the request state of a feature is a messy business. From my own experience, some things to be careful of:
--The ControlEvent to fire last wins. So, in your example if all requests get made as Remove = All, then some AddLocal events fire, reasonably you would expect only the AddLocal'd features to be selected.
--However, if you've got the ADDLOCAL property set, this is going to also have an effect on selections (and this trumps previous 'Remove' ControlEvents).
--Similarly, REMOVE being set has an effect.
--If this is a Major Upgrade, potentially you might end up with MigrateFeatureStates interfering.
--Lastly, if this is an InstallScript MSI, keep in mind that feature selections get passed in the form of ADDLOCAL based on dialog input. This doesn't sound like it's the case, though, since ControlEvents are in the equation, but it's a 'Gotcha'.
--I don't recall offhand if this trumps ControlEvents or ADDLOCAL, REMOVE, but try double checking to see if any are marked as 'Required'.
If all else fails, you might just post your *.ism and install log and it might provide the answer.
--Cary
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 14, 2010
11:14 PM
Ok so I think I have it worked out.
I changed all features to have a higher INSTALLSTATE so they were defaulted to not install. I then deleted all the REMOVE control events and only left the AddLocal control events. This appears to have doen the trick.
I think it was your point about only the latest control event running that triggered the thought. Your help and time much appreciated. Thanks
I changed all features to have a higher INSTALLSTATE so they were defaulted to not install. I then deleted all the REMOVE control events and only left the AddLocal control events. This appears to have doen the trick.
I think it was your point about only the latest control event running that triggered the thought. Your help and time much appreciated. Thanks
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)