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: Questions about the Suite Project
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
‎Sep 13, 2011
08:23 AM
Questions about the Suite Project
I would like to check if the Suite Project can be used according of my users requirements.
As for today we have a in-house developed programs that interview the user for all input information such as:
* Target folders for various sub installs.
* SQL Server connection information for database activities.
* Etc.
Validity of input is of course required.
My questions are:
1) Is it possible to do stuff like this in a Suite Project?
2) Where is the documentation?
Thanks in advance.
As for today we have a in-house developed programs that interview the user for all input information such as:
* Target folders for various sub installs.
* SQL Server connection information for database activities.
* Etc.
Validity of input is of course required.
My questions are:
1) Is it possible to do stuff like this in a Suite Project?
2) Where is the documentation?
Thanks in advance.
(7) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 14, 2011
12:47 PM
All you request should be possible: selectable folders for each package are practically built-in, however the SQL dialog question is involved, and the documentation doesn't cover all the pieces yet. We're planning to blog on this later this year; if you need some early guidance on this now, maybe we can post some quick steps here.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 15, 2011
12:25 AM
Documentation will be great - the sooner the better.
Few points to elaborate:
1. About target folders, in some of our installations we have more then INSTALLDIR, for example: we need to point to database folders, log folders, Etc.
an some of the targets will be asked conditionally.
2. How do I enable feature selection from a suite contained MSI.
3. according to feature selections I need to proceed with the interview, for example I have an installation that has a server side which contains database, if the feature is selected then the user has a dialog to enter a local SQL server instance & if just the client feature is selected a different dialog ask connection information to a, possibly, remote SQL server instance.
Thanks again.
Few points to elaborate:
1. About target folders, in some of our installations we have more then INSTALLDIR, for example: we need to point to database folders, log folders, Etc.
an some of the targets will be asked conditionally.
2. How do I enable feature selection from a suite contained MSI.
3. according to feature selections I need to proceed with the interview, for example I have an installation that has a server side which contains database, if the feature is selected then the user has a dialog to enter a local SQL server instance & if just the client feature is selected a different dialog ask connection information to a, possibly, remote SQL server instance.
Thanks again.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 16, 2011
03:06 PM
These are just pointers; I hope to see fuller documentation before too long (either on helpnet or in blog posts).
For 1 - take a look at how the Browse for installation folder page works. You'll see it ties an edit control to a suite property, and then the suite property is passed to the MSI on the command line of its Install operation. Follow this pattern, but use other properties to pass anything your MSI can take.
For 2 - there's no UI for this yet, so officially it hasn't been tested yet. But with that caveat, we'd love to see feedback on whether it suits your needs. Start by setting up your main feature tree, and then look at the underlying XML in your project file. You can follow the patterns you see there, but add {SUITE-GUID-HERE}:feature-name-here to the lnstall attribute of the SelectionTree//Selection elements.
For 3 - you can do part of this like in 1, but the fuller answer where you might want to browse available options and show them in your wizard requires more than I can cover here today. Keep an eye out for upcoming help and blogs, like I mentioned, as we know this is an important scenario to support.
For 1 - take a look at how the Browse for installation folder page works. You'll see it ties an edit control to a suite property, and then the suite property is passed to the MSI on the command line of its Install operation. Follow this pattern, but use other properties to pass anything your MSI can take.
For 2 - there's no UI for this yet, so officially it hasn't been tested yet. But with that caveat, we'd love to see feedback on whether it suits your needs. Start by setting up your main feature tree, and then look at the underlying XML in your project file. You can follow the patterns you see there, but add {SUITE-GUID-HERE}:feature-name-here to the lnstall attribute of the SelectionTree//Selection elements.
For 3 - you can do part of this like in 1, but the fuller answer where you might want to browse available options and show them in your wizard requires more than I can cover here today. Keep an eye out for upcoming help and blogs, like I mentioned, as we know this is an important scenario to support.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 17, 2012
08:25 AM
MichaelU wrote:
For 3 - you can do part of this like in 1, but the fuller answer where you might want to browse available options and show them in your wizard requires more than I can cover here today.
I am really interested in issue number three. To support things like:
feature1 has no user information gathered,
feature2 needs user to input DNS server name and port,
feature3 needs user input for DNS server name and port,
feature4 needs security token server info
If feature1 is selected then no custom dialogs will be displayed. If feature2 and feature3 are selected then the same information will be only asked once and/or any other combination.
MichaelU wrote:
Keep an eye out for upcoming help and blogs, like I mentioned, as we know this is an important scenario to support.
I am unable to find support in the help/blogs.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 17, 2012
10:20 AM
We really need to do some more plumbing to make this convenient. But to handle this today I think I would use a UI action plus the Visible condition on multiple pages.
- On the feature selection (or any equivalent) page's next button, set some properties in a UI extension action:
- GETSERVERINFO=true - if either feature 2 or 3 are enabled
- GETTOKENINFO=true - if feature 4 is enabled
- set each to empty or false otherwise
- GETSERVERINFO=true - if either feature 2 or 3 are enabled
- Then on the subsequent information gathering pages, specify Visible = {Binding GETSERVERINFO=true} or {Binding GETTOKENINFO=true} respectively
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 04, 2012
12:56 PM
Michael,
I tried to use the visibility syntax you gave below, but it doesn't work (using 2012 Spring SP1)
It seems to me that multiple bindings can not be OR'ed. Could that be a regression in the latest release?
What I need to do is to show different configuration dialogs depending on the features the user selected. Some Dlgs are for one feature only, others are shared among several features. So what I tried was to follow your instructions and set a property first in the action and then specify the binding to the property in the Visible field of the Dialog.
It works fine when I only have one Binding. E.g. {Binding SELECTED_PRODUCT=FEATURE1}
--> the Dlg is shown when FEATURE1 is being selected.
As soon as I add a second condition, the dialog is skipped alltogether
e.g. {Binding SELECTED_PRODUCT=FEATURE1} or {Binding SELECTED_PRODUCT=FEATURE2}
--> the Dialog is not shown for either FEATURE1 or FEATURE2
Any ideas how to fix this?
I tried different variations, == instead of =, changed capitalization, used different variables for each product and setting them to true/false like in your example. No success.
-Sandra
I tried to use the visibility syntax you gave below, but it doesn't work (using 2012 Spring SP1)
It seems to me that multiple bindings can not be OR'ed. Could that be a regression in the latest release?
What I need to do is to show different configuration dialogs depending on the features the user selected. Some Dlgs are for one feature only, others are shared among several features. So what I tried was to follow your instructions and set a property first in the action and then specify the binding to the property in the Visible field of the Dialog.
It works fine when I only have one Binding. E.g. {Binding SELECTED_PRODUCT=FEATURE1}
--> the Dlg is shown when FEATURE1 is being selected.
As soon as I add a second condition, the dialog is skipped alltogether
e.g. {Binding SELECTED_PRODUCT=FEATURE1} or {Binding SELECTED_PRODUCT=FEATURE2}
--> the Dialog is not shown for either FEATURE1 or FEATURE2
Any ideas how to fix this?
I tried different variations, == instead of =, changed capitalization, used different variables for each product and setting them to true/false like in your example. No success.
-Sandra
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 04, 2012
04:12 PM
Sorry for the confusion in my example; the or was separating two different cases for which you'd provide a single Binding. We don't support multiple conditions at this time. If you need to consider multiple things, you can either find ways to stack them (like the license agreement dialog that requires scrolling), or you can write an extension that summarizes multiple conditions into a single property.