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
- :
- Another way
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
‎Jul 11, 2007
12:20 PM
Disable Next Button in CustomSetup - The old question
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 ^^
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 ^^
(15) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 12, 2007
07:42 AM
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)".
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 12, 2007
08:41 AM
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...
May you tell me, where I have to put the code you suggested? I think I searched at the wrong position...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 12, 2007
08:55 AM
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."
See the help topic "Using InstallScript" for an explanation of how, "To author an InstallScript custom action and execute it in your installation."
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 12, 2007
10:25 AM
oh, ok. I will try tomorrow, thx for the tip!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 17, 2007
03:41 AM
I tried very hard to solve this problem but I still don't get it work:
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?
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?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 18, 2007
04:40 AM
Is there no help for a poor soul like mine? 😮
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 18, 2007
12:54 PM
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.
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.
Stefan Krueger
InstallSite.org
InstallSite.org
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 18, 2007
01:41 PM
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! 🙂
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 18, 2007
03:07 PM
Not sure if that would work well, but you could move those core components to another, Ãnvisible, top level feature.
Stefan Krueger
InstallSite.org
InstallSite.org
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 18, 2007
03:10 PM
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??
Could you please tell me what custom actions are good for in practice? For which puposes where they built in??
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 19, 2007
07:59 AM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 24, 2007
01:59 AM
*push* please
Update: I managed to split my conditions. My first condition only is responsible for normal installing. My second only for modifying.
First:
Second:
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?
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?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 08, 2007
02:33 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 08, 2007
03:08 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 08, 2007
03:19 PM
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.