Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Best approach for conditional features?


2 replies to this topic

gruntus

gruntus
  • Members
  • 3 posts

Posted 03 August 2005 - 02:25

Hello All,

I have to build a large data installation project (approx 8Gig). Their is a requirement that the end user should only install a subset of the data (only the data they need - not the full 8 Gig). The subset will be determined at runtime by allowing the user to enter the filter conditions through the use of a custom dialogs. We have currently identified about 600+ seperate data components.

The custom dialogs are based on the "Using Dual ListBoxes as Replacement for a Multi-Selection ListBox". Following is an example of one of these dialogs:

1. Region Selection. Able to select 1 or more regions. A data component can belong to 1 or more regions.

We have another 3 dialogs that provide addiontal filter conditions.

Because of these requirement it seems my only approach is to create a 1:1 relationship between features and components (i.e. have 600+ features). At runtime the installer will then need to create a subset of the data by enabling/disabling the features.

What is the best approach for supplying this level of fucntionality.

Feature Conditions ?
Building the Feature Table at runtime ?
AddLocal ControlEvent from a custom action (can this be done) ?
Any other approach ?


I have attempted to use feature conditions but I have found that I need to perfrom the Costing (CostFinalize, etc) after the dialogs. Is this a bad approach?

I have attempted building the feature table at runtime....I failed miserably.....any examples on how to do this.

I have not yet attempted to use AddLocal ControlEvent from a custom action (it probably can't be done). The custom action would allow me to build a feature string (containing the subset of features) and then raise the AddLocal ControlEvent .

Any help would be greatly appreciated.
Grant.

Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 03 August 2005 - 10:05

8GB?! My current project is a humble 4.5 GB, 200+ features, etc... And it tries to create its own feature tree as well, but only because InstallShield takes too much time to build the MSI.

On your questions:
* Use Feature Conditions for initial default states, or hiding features. These conditions are only evaluated during the costing process, not afterwards.
* You can build the feature table at runtime, but only before the Costing process. Remember that changed tables are not persisted, so make sure you build the SAME feature table every time, otherwise maintenance, repair and uninstall do not work properly.
* In a custom action, you can change the feature state by MsiSetFeatureState.

Anyway I don't recommend building the feature table (although I'm creating code to do so right now). Do the costing at start up, manipulate feature states use the appropriate functions afterwards (you can *not* use control events, they can only be used by controls).

gruntus

gruntus
  • Members
  • 3 posts

Posted 04 August 2005 - 08:11

I managed to used a combination of Custom Action and the Control events.

In the custom action I build a property which has the required features. Then the AddLocal Control Event uses the property I created in the custom action.

Thanks for the response.

Grant.