Disable Next Button in CustomSetup - The old question

[wuschl]

Hi, following problem:

I have a setup with six features:
Feature 1,
Sub_Feature 1,
Sub_Feature 2,
Sub_Feature 3,
Sub_Feature 4,
Sub_Feature 5

In the CustomSetup Dialog I wanted to disable the Next Button as long as the user has not chosen Feature 1 and at least one Sub_Feature (which one does not matter). So, I went through tons of threads which all said that it is not possible to change the state of the button live at runtime.
The next idea was to deactivate the function of the button. The user should not be able to get to another dialog by clicking this button as long he does not fulfill the requirements mentioned above. I managed to set a condition which got it to work:

Event: NewDialog
Argument: ReadyToInstall
Condition: OutOfNoRdDiskSpace <> 1 And Not (&Feature1<>3 Or &Sub_Feature 1<>3 And &Sub_Feature 2<>3 And &Sub_Feature 3<>3 And &Sub_Feature 4<>3 And &Sub_Feature 5<>3)

This is working well for normal installing, but when it comes to the modify dialog I get into troubles. I am only asking for the Action state of the feature, but not for the Installed state which I need in the Modify dialog. So that would not be a big problem, I only had to create a bigger statement.
Nope! The condition field only exacts 256 letters. So what should I do?

Is there any easier way to solve this problem, which I do not see at the moment? I spent several hours and did not com to a conclusion, so please: HELP! 😉

I am speaking about a Basic InstallShield Project.

PS: Sry for bad English ^^

[jcpohusk]

You can use an InstallScript Custom Action to control the "next" button. You will need to do some programming to detect which features are selected using calls to "FeatureIsItemSelected ( szFeatureSource, szFeature )" and then calls to "Disable(NEXTBUTTON)" and "Enable(NEXTBUTTON)".

[wuschl]

I would need to build an Installscript Project, is this right? At the moment I am creating the Installer in a Basic MSI Project, because I am not really familiar to Installscript. I tried to find the code, where the Button is created in the script, when I also created an InstallScript Project yesterday, but did not find anything.

May you tell me, where I have to put the code you suggested? I think I searched at the wrong position...

[jcpohusk]

No, you do not have to build an InstallScript project. You can build an InstallScript Custom Action. See Installation Designer->Behavior and Logic->Custom Actions in the InstallShiled IDE.

See the help topic "Using InstallScript" for an explanation of how, "To author an InstallScript custom action and execute it in your installation."

[wuschl]

oh, ok. I will try tomorrow, thx for the tip!

[wuschl]

I tried very hard to solve this problem but I still don't get it work:

hwndDlg = CmdGetHwndDlg(SD_DLG_COMPONENTTREE);
hwndItem = GetDlgItem(hwndDlg, NEXT);
EnableWindow(hwndItem, FALSE);	

I fire this Custom Action with "DoAction" on the SelectionTree and I tested with a simple MessageBox, so I got this right. My problem seems to be the script. Describes "NEXT" really the NextButton and do I choose the right dialog box with "SD_DLG_COMPONENTTREE"?

EDIT: Is it normal that my Custom Action slows the Installer down dramatically? It takes my CA some seconds to raise the MessageBox with which I tested the script. Am I doing anything wrong, or is this normal?

[wuschl]

Is there no help for a poor soul like mine? 😮

[Stefan_Krueger]

I believe this will not work in a Basic MSI project.
One thing you could try to overcome the string limit (and to make your condition more readable) is to split it into several steps. For each feature you could set a property based on it's selection. Then use those properties in your final condition.

A copletely different approach: what happens if there are no components in the parent feature? I think in this case when you un-select all children the parent also gets unselected.

[wuschl]

Stefan Krueger wrote:
I believe this will not work in a Basic MSI project.

Ok... So now I know how to build custom actions. That's not bad anyway. 😉 One question for overall understanding: When does it make sense to use custom actions, if it is not really possible to change dialogs with them?

Stefan Krueger wrote:
One thing you could try to overcome the string limit (and to make your condition more readable) is to split it into several steps. For each feature you could set a property based on it's selection. Then use those properties in your final condition.

Ok, so tomorrow I will try to build custom properties.

Stefan Krueger wrote:
A copletely different approach: what happens if there are no components in the parent feature? I think in this case when you un-select all children the parent also gets unselected.

In my parent feature lie the main features of the program. Where should I put them if not there? Into another Sub feature? Then I also have the problem that this Sub Feature and a second one have to be selected to continu the setup.
Or did I missunderstand you?

Thanks for your help! 🙂

[Stefan_Krueger]

Not sure if that would work well, but you could move those core components to another, ínvisible, top level feature.

[wuschl]

Ok, I will see tomorrow. Thanks again.
Could you please tell me what custom actions are good for in practice? For which puposes where they built in??

[wuschl]

Stefan Krueger wrote:
A copletely different approach: what happens if there are no components in the parent feature? I think in this case when you un-select all children the parent also gets unselected.

If you deselect the parent feature then all child get deselected but this does not work the other way, unfortunately, also if there are no components in the parent feature.

So now I have to overcome the condition string limit. I try to do this still with a custom action, when my requirements are not fulfilled, my function sets the property "InstallFeaturesOk" to "Yes", if not to "No". That's working but I would like to know if there are other methods to overcome the string limit without using a custom action. Is there a special trick?

The main problem I have with the custom action is that it is really slow. As I mentioned some posts before, it takes approxiametely 4 seconds from calling the custom action to exiting it. Because I call this custom action by manipulating the Selection Tree in the custom setup dialog the custom action seems to be called several times (3?) with each change on the selection tree.

Are there any methods to speed up my custom action or is there any other way to work around the condition string limit??

Sorry for demanding your time I understand everyone is busy around here.

[wuschl]

*push* please

Update: I managed to split my conditions. My first condition only is responsible for normal installing. My second only for modifying.
First:

Not Installed And OutOfNoRdDiskSpace <> 1 And &BW>2 And &CUIC>2 Or &CUIM>2 Or &CM>2 Or &SUIC>2 Or &AMUIC>2

Second:

Installed And OutOfNoRdDiskSpace <> 1 And &BW>2 Or &CUIC>2 Or &CUIM>2 Or &CM>2 Or &SUIC>2 Or &AMUIC>2

The first one is working perfectly. The second does everything right in all cases. My purpose is that in all cases (normal install AND modify) "BW" is a MUST and that the user has to install at least one of the other features. It does not matter if he chooses "CUIC", "SUIC" or "AMNUIC", but he has to choose one for coninuing.

In my second condition I am checking if the user has chosen the required features, but I do not take care of already installed features. I tried with !BW>2 but that failed. I also tried to combine &BW>2 with !BW>2 by linking them with "OR" but this was also not successfull.

Is there any possibility to guarantee that the user always installs at least "BW" and one of the other features in the Modify Dialog regardless of which features where already installed?

[darin_magoffin]

Instead of using all the feature names again for the conditions, you can use the "Installed" property to handle the Modify part of the install for example.
Press the Next button
NewDialog (&Feature1 = 3 Or &Feature2 = 3) Or (Installed)

Once the customer makes their feature selection and installs the product, then going into the Modify install the "Installed" property will allow the Next button to go through. If they unselect all the features, then it essentially does a REMOVE="ALL" which is great. If they unselect a single feature, then it just removes the unselected feature. If they leave it the same it goes on and I believe it will do a repair on all the features that were originally installed.

Adding the Or (Installed) may allow you to get your entire condition statement in less than the 256 character maximum for the field.

[Kelter]

alternatively, you could break up the long conditional expression into a few chunks. Set up the following events, in order, for the Next button:

Event: [CONDITION_A]
Argument: TRUE
Condition: OutOfNoRdDiskSpace <> 1 And Not (&Feature1<>3 Or &Sub_Feature 1<>3 And &Sub_Feature 2<>3 And &Sub_Feature 3<>3 And &Sub_Feature 4<>3 And &Sub_Feature 5<>3)

Event: [CONDITION_B]
Argument: TRUE
Condition:

Event: NewDialog
Argument: ReadyToInstall
Condition: CONDITION_A OR CONDITION_B

You could use this logic to chain together as complex a conditional statement as you wish.

Unfortunately, FeatureIsItemSelected() only works in an installscript project. It won't work in an InstallScript custom action within a Basic MSI project. I've tried that before too.

[Kelter]

If you want to do some more advanced processing within a dialog (like something you'd want to script, perhaps) you can do so by calling an IS custom action, and having the custom action "return" a value via MsiSetProperty(). You can then use that property as a condition in another event on the same control as long as they are arranged in the proper order.