cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
PaulEden
Level 4

Controlling Suite Wizard Flow

Hi

I'm looking to make decisions in the flow of the installation wizard based on items selected in the InstallationFeatures screen. For example, if I have 2 features, for each that get selected I want to be able to display an addiotnal wizard screen for the gathering of settings (so that they can be gathered prior to actually installing, as a form of headless install).

Is this possible?

Many thanks

Paul
Labels (1)
0 Kudos
(9) Replies
MichaelU
Level 12 Flexeran
Level 12 Flexeran

I would start with the suggestions on this thread. Unfortunately I'm not quite sure how to hook up alternate next pages based on the value of a property, so today you might have to use the button approach.
0 Kudos
PaulEden
Level 4

The button aproach would probably work if it was an "OR" scenario but mine is "AND/OR" and I can't see how this would work for that.

If the selected feature is queryable through a property, I figured I could just set the visibility of the form to True / False based on the feature "selected" value. My problem is that I have no idea how to query if a feature has been selected, or if is possible.

psudo code for the visibility property would resemble something like:

.selected

thanks

paul
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

Oh right, great thought on the Visibility part. Proof I'm still learning how to use Suite projects correctly.

Just like you can use an Enabled setting of:
{Binding FEATURE[feature name].actionState==}

to disable a checkbox when a feature is selected for installation, you could use a Visibilty setting of:
{Binding FEATURE[feature name].actionState==install}

on a dialog scheduled after the feature selection tree. This would only show up if the feature was selected for install. If you instead need to show this during maintenance, you could check FEATURE[feature name].installState instead for, say, != 0.
0 Kudos
skolte
Level 7

Paul,

Yes, it is very much possible.

If you go to Behavior and Logic > InstallScript and once the empty script shows up, look for two dropdowns at the top of the screen. Select Before Move Data in First dropdown and select OnFirstUIBefore event. InstallShield should automatically place bunch of code in the script. This is the default code that runs when you run the installer. Notice how they have labels and different dialogs, and goto labels.

As far as adding your own screens to installer is concerned you have a few options, if you want to accept some text parameters or accept inputs through radio buttons or checkboxes you can use the built-in functions like AskText(), AskOptions() and AskYesNo() etc. InstallShield will automatically put in dialogs with appropriate labels and textboxes/radio/checkboxes as you want. You can either set global variables in your script or set your own custom MSI properties using MsiSetProperty().

If you want to design your own dialog, that's also possible using Dialog UI Editor. The idea is pretty much the same except you will have to write some InstallScript code so that the dialog is initialized properly. There are several samples that show this.

Lastly, you want to use selected features as conditions to display your screens. You can use FeatureIsItemSelected() method to check if the feature is selected and if it is, show the additional screens you want.

Let me know if you need more help.
SK

SK
0 Kudos
PaulEden
Level 4

I would imagine this would work in the context of an MSI, but in suite projects there is no capability for intelligent logic of this kind.



skolte wrote:
Paul,

Yes, it is very much possible.

If you go to Behavior and Logic > InstallScript and once the empty script shows up, look for two dropdowns at the top of the screen. Select Before Move Data in First dropdown and select OnFirstUIBefore event. InstallShield should automatically place bunch of code in the script. This is the default code that runs when you run the installer. Notice how they have labels and different dialogs, and goto labels.

As far as adding your own screens to installer is concerned you have a few options, if you want to accept some text parameters or accept inputs through radio buttons or checkboxes you can use the built-in functions like AskText(), AskOptions() and AskYesNo() etc. InstallShield will automatically put in dialogs with appropriate labels and textboxes/radio/checkboxes as you want. You can either set global variables in your script or set your own custom MSI properties using MsiSetProperty().

If you want to design your own dialog, that's also possible using Dialog UI Editor. The idea is pretty much the same except you will have to write some InstallScript code so that the dialog is initialized properly. There are several samples that show this.

Lastly, you want to use selected features as conditions to display your screens. You can use FeatureIsItemSelected() method to check if the feature is selected and if it is, show the additional screens you want.

Let me know if you need more help.
SK

SK
0 Kudos
PaulEden
Level 4

Hi, thanks for the reply.

I've tried to put this property usage in place, but it seems to be generating an exception when it is evaluated.

Given the following:
Feature name = DB
Containing 1 package = DB

I have removed the "Install" button (because I don't want the install to start) and replaced it with a "Next" as the configure screen is next in the wizard list.

I set the property on the config screen as follows, as I wanted the abilty to show the screen during maintenance:

{Binding FEATURE[DB].installState != 0}

If I select to debug the exception it boils down to an unhandled win32 exception [3384], though I can't get anything more useful than that.

Alternatively if I set the visible porerty to the following, the config screen does not dispay irrespective of it being a selected feature:

{Binding FEATURE[DB].actionState == install}

Have any idea what could be going wrong?

many thanks

paul


MichaelU wrote:
Oh right, great thought on the Visibility part. Proof I'm still learning how to use Suite projects correctly.

Just like you can use an Enabled setting of:
{Binding FEATURE[feature name].actionState==}

to disable a checkbox when a feature is selected for installation, you could use a Visibilty setting of:
{Binding FEATURE[feature name].actionState==install}

on a dialog scheduled after the feature selection tree. This would only show up if the feature was selected for install. If you instead need to show this during maintenance, you could check FEATURE[feature name].installState instead for, say, != 0.
0 Kudos
PaulEden
Level 4

OK, I've since found that spaces make a lot of difference.

If i remove th spaces in

{Binding FEATURE[DB].actionState == install}

it works.


The variation using "installState", however, still generates the exception regardless of spaces being removed.

Is this an InstallShield bug?

thanks

paul
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

The space thing is annoying. Right now it's a doc bug of sorts, but we need to make the syntax more forgiving, so long term it's a code bug.

As for the comparison on installState, sounds like it. I'll double-check on the != case when I can scrounge up some time (right now it looks like it may not be implemented). Until then, perhaps see if ==2, or ==3 does what you need.
0 Kudos
rajeev15
Level 3

How to set the visibility condition {Binding FEATURE[F1].actionState == install} using GUI
0 Kudos