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: Feature Selection
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
‎Jun 02, 2010
07:34 AM
Feature Selection
Is there a way to have a feature automatically be set to "Not Available" if another Feature is selected to not be installed. These are not Parent/Child Features.
Example:
|--API1
|--API2
|--Test Tools
|--Test API1
|--Test API2
If API2 is selected to not be installed, how can "Test API2" automatically be unselected and displayed with an X has not going to be installed.
Basic MSI project
Custom Setup Dialog
Thanks for any help.
Example:
|--API1
|--API2
|--Test Tools
|--Test API1
|--Test API2
If API2 is selected to not be installed, how can "Test API2" automatically be unselected and displayed with an X has not going to be installed.
Basic MSI project
Custom Setup Dialog
Thanks for any help.
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 03, 2010
05:56 PM
I believe there's nothing built in to handle this kind of feature dependency, besides making "Test API2" a subfeature of "API2".
It wouldn't look the same, but for that behavior you could perhaps add a conditional Remove control event that deselects "Test API2" if "API2" isn't selected.
It wouldn't look the same, but for that behavior you could perhaps add a conditional Remove control event that deselects "Test API2" if "API2" isn't selected.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 03, 2010
10:05 PM
I work on massive installers that derive from a product line of 15,000+ files forming 200+ features from 20+ service families. Frankly Windows Installer's tree format of relating variation points and dependencies doesn't always cut it. A 'feature' ( overloaded term ) at our company often has complex dependencies and cross multiple service families.
Robert is right, you could make the testapi features children of the apis themselves but then you don't see them grouped together. You could include the components for the api feaures in the testapi features so that they go together but then it gives you the impression that the apis aren't being installed when in fact they are. You could also write your testapi components to fail gracefully if the api isn't present. ( runtime message, sorry api not detected ).
You might want to just not show the custom setup dialog and instead have your own custom dialog that gets the input from the user and then translates it into feature states.
Maybe Robert has thought about this deeper then I have and has some suggestions that would help me rethink my understanding of this area.
Robert is right, you could make the testapi features children of the apis themselves but then you don't see them grouped together. You could include the components for the api feaures in the testapi features so that they go together but then it gives you the impression that the apis aren't being installed when in fact they are. You could also write your testapi components to fail gracefully if the api isn't present. ( runtime message, sorry api not detected ).
You might want to just not show the custom setup dialog and instead have your own custom dialog that gets the input from the user and then translates it into feature states.
Maybe Robert has thought about this deeper then I have and has some suggestions that would help me rethink my understanding of this area.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 04, 2010
05:26 AM
Thanks for the replies. I'll report back the the development team (Was their idea) and recommend I make the test tool a child of the API. I don't believe the extra work is worth while in this case.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 04, 2010
03:33 PM
Christopher Painter wrote:
Maybe Robert has thought about this deeper then I have and has some suggestions that would help me rethink my understanding of this area.
No deep thinking at this end. From the what-gets-installed standpoint, having strictly enforced "feature" dependencies makes perfect sense, though no package management system seems immune to dependency woes. From a UI standpoint, though, the danger is making it feel like a game of Lights Out, where turning on one light turns some others on and some others off according to a hidden rule...
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)