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: Issues with Canceling from Suite wizard pages
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
‎Mar 06, 2012
05:12 PM
Issues with Canceling from Suite wizard pages
I have noticied the following issues:
1) If you decide to cancel from a Suite wizard page, you are always redirected to the InstallationComplete page (somewhat akin to a Finish dialog). If you make a new wizard page and condition it to be the cancel page and condition the InstallationComplete page not to display on a cancel, you get an error. Is there a way to redirect cancel to some other wizard page?
2) If you attach an action to the cancel button, say a {SetProperty ...} or {SetActivePage ...}, it will immediatedly happen. Unfortunately, the cancel button comes with a confirm dialog. If you decide not to cancel, the actions attached to the button still happen. Is there a way to get around this? It would seem to make more sense to have the actions happen after you have confirmed that you are going to cancel.
1) If you decide to cancel from a Suite wizard page, you are always redirected to the InstallationComplete page (somewhat akin to a Finish dialog). If you make a new wizard page and condition it to be the cancel page and condition the InstallationComplete page not to display on a cancel, you get an error. Is there a way to redirect cancel to some other wizard page?
2) If you attach an action to the cancel button, say a {SetProperty ...} or {SetActivePage ...}, it will immediatedly happen. Unfortunately, the cancel button comes with a confirm dialog. If you decide not to cancel, the actions attached to the button still happen. Is there a way to get around this? It would seem to make more sense to have the actions happen after you have confirmed that you are going to cancel.
(7) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 07, 2012
08:18 AM
Right now, the target page for canceling or errors is always the final page in the wizard. I agree that we need to offer more control here, and would like to make sure we consider your use case when we extend this. Can you clarify what you're trying to do differently from the provided completed page, and in response to what scenarios?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 07, 2012
11:56 AM
Thanks Micahel, but the problem goes deeper than that. If I do cancel from the welcome dialog, or the License agreement dialog, or the Install Type dialog then it does go to the last dialog. I discovered that yesterday after my post.
However, if one of the prerequisites errors out and causes the bootstrapper to stop, it goes to the next dialog in the sequence. If you cancel from the progress dialog, it also goes to the next dialog in the sequence. In these situations, the next dialog in the sequence is the InstallationComplete dialog.
These error conditions are very serious and I need to go to an error dialog. However, I am ending up at the InstallationComplete dialog. If I position an error dialog at this location and the InstallationComplete dialog after, then the good install also displays the error dialog.
Is there some way I can differentiate between a failed install and a good install so that I can display an error dialog for a failed install or the InstallationComplete dialog for a good install?
However, if one of the prerequisites errors out and causes the bootstrapper to stop, it goes to the next dialog in the sequence. If you cancel from the progress dialog, it also goes to the next dialog in the sequence. In these situations, the next dialog in the sequence is the InstallationComplete dialog.
These error conditions are very serious and I need to go to an error dialog. However, I am ending up at the InstallationComplete dialog. If I position an error dialog at this location and the InstallationComplete dialog after, then the good install also displays the error dialog.
Is there some way I can differentiate between a failed install and a good install so that I can display an error dialog for a failed install or the InstallationComplete dialog for a good install?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 07, 2012
12:28 PM
So here is what I am trying to do.
I want to be able to have a different wizard page for an Error and a different wizard page for a good install. If you do cancel, as I mentioned above, you do go to the final page of the install. However, canceling from the progress dialog or encountering an error when running the bootstrapper does not cause you to move to this final page. It goes to the next page in the sequence. So you really need three different pages.
One for canceling from the standard wizard page, one for an error encountered in the bootstrapper (in this case you set the package condition to abort if it encountered an error), and one for a good install.
There is actually a fourth condition, and that is canceling from the progress dialog. In this case you could combine the cancel from the progress dialog with the error dialog.
There either needs to be a way to condition the text to distinguish between an error and a good install or their needs to be a way to use two different dialogs.
In my particular case the InstallationComplete dilaog is used to launch a separate install from the Finish button, so I need to differentiate between an error and a good install.
I want to be able to have a different wizard page for an Error and a different wizard page for a good install. If you do cancel, as I mentioned above, you do go to the final page of the install. However, canceling from the progress dialog or encountering an error when running the bootstrapper does not cause you to move to this final page. It goes to the next page in the sequence. So you really need three different pages.
One for canceling from the standard wizard page, one for an error encountered in the bootstrapper (in this case you set the package condition to abort if it encountered an error), and one for a good install.
There is actually a fourth condition, and that is canceling from the progress dialog. In this case you could combine the cancel from the progress dialog with the error dialog.
There either needs to be a way to condition the text to distinguish between an error and a good install or their needs to be a way to use two different dialogs.
In my particular case the InstallationComplete dilaog is used to launch a separate install from the Finish button, so I need to differentiate between an error and a good install.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 08, 2012
08:44 AM
Hmm. It sounds like you need one of two things. Either you need the ability to control which final page you see after various ways the suite may end (including package error, user cancel, overall success), or you need the ability to condition your launching action against which of those various ways the suite got to the final page.
I think we might be able to do the latter today, whereas the former will definitely require some changes. One thing that differs between success and failure/cancel completions is the value of the ISInstallStatus property. The {Open ...} condition takes the form: {Open {p1},{p2==v2}}, where p1 is the property containing the document or executable to open, p2 is a property to compare, and v2 is the value against which to compare it. So you could try {Open {SomeProp},{ISInstallStatus==stringid}} where stringid is literally one of IDS_INSTALL_SUCCESS, IDS_UNINSTALL_SUCCESS, or IDS_SUITE_INTERRUPTED. You can place multiple open actions of this format in the same action field, so you could potentially launch different things for each status. (I'm just not sure whether this will compare stringid to stringid, text to text, or text to stringid - hopefully it's one of the first two.)
I think we might be able to do the latter today, whereas the former will definitely require some changes. One thing that differs between success and failure/cancel completions is the value of the ISInstallStatus property. The {Open ...} condition takes the form: {Open {p1},{p2==v2}}, where p1 is the property containing the document or executable to open, p2 is a property to compare, and v2 is the value against which to compare it. So you could try {Open {SomeProp},{ISInstallStatus==stringid}} where stringid is literally one of IDS_INSTALL_SUCCESS, IDS_UNINSTALL_SUCCESS, or IDS_SUITE_INTERRUPTED. You can place multiple open actions of this format in the same action field, so you could potentially launch different things for each status. (I'm just not sure whether this will compare stringid to stringid, text to text, or text to stringid - hopefully it's one of the first two.)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 08, 2012
08:20 PM
Thanks Michael, I didn't notice that you had replied. Here is what I did do:
Good Install
InstallComplete dialog
set visible {Binding ISInstallStatus==IDS_INSTALL_SUCCESS}
Install error or canceled from progress dialog
InstallInterrupted dialog
set visible {Binding ISInstallStatus==IDS_SUITE_INTERRUPTED}
Normal install cancel
InstallCanceled dialog
Placed this as the final dialog.
This seems to work like a charm.
Thanks,
--Kim
Good Install
InstallComplete dialog
set visible {Binding ISInstallStatus==IDS_INSTALL_SUCCESS}
Install error or canceled from progress dialog
InstallInterrupted dialog
set visible {Binding ISInstallStatus==IDS_SUITE_INTERRUPTED}
Normal install cancel
InstallCanceled dialog
Placed this as the final dialog.
This seems to work like a charm.
Thanks,
--Kim
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 09, 2012
08:19 AM
I like that visibility approach - but make sure to consider IDS_UNINSTALL_SUCCESS. I'll have to think about it a bit more, and consider incorporating it wholesale; it certainly is more flexible than just conditioning the {Open ...} action. (And make sure it doesn't break in the next version, of course.)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 09, 2012
09:47 AM
Thanks.
I hadn't thought about that.
I hadn't thought about that.
![](/skins/images/3B39CE851FDD5528C393F146EB70A2D0/responsive_peak/images/icon_anonymous_message.png)