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
- :
- Can't get Ok/Cancel buttons on a suite secondary window to trigger a "suite action"
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
![](/skins/images/CC38E504FC9E1309DC48ACFEB4925670/responsive_peak/images/icon_anonymous_message.png)
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 12, 2014
08:17 AM
Can't get Ok/Cancel buttons on a suite secondary window to trigger a "suite action"
I've been trying to get Ok/Cancel (control) buttons on a suite secondary window to trigger a "suite action" when clicked. This is so I can determine which of the buttons has been selected to close the window.
Although the secondary window is displayed and closes when one of these buttons is clicked it does not trigger the suite action. There's nothing in the install log file to indicate the action was triggered either.
As an experiment if I create a "windows exited" event on the secondary window to call the same suite action then all works fine and the action is called when the window closes. However this doesn't help me determine which button actually closed the window.
As a second experiment I changed the suite action to simply set a suite property, but that didn't work either.
Note: I've named the buttons IDOK and IDCANCEL as I understand is a requirement.
Anyone know of a way around this?
This is IS2014 Premier Edition by the way.
Although the secondary window is displayed and closes when one of these buttons is clicked it does not trigger the suite action. There's nothing in the install log file to indicate the action was triggered either.
As an experiment if I create a "windows exited" event on the secondary window to call the same suite action then all works fine and the action is called when the window closes. However this doesn't help me determine which button actually closed the window.
As a second experiment I changed the suite action to simply set a suite property, but that didn't work either.
Note: I've named the buttons IDOK and IDCANCEL as I understand is a requirement.
Anyone know of a way around this?
This is IS2014 Premier Edition by the way.
(7) Replies
![](/skins/images/CC38E504FC9E1309DC48ACFEB4925670/responsive_peak/images/icon_anonymous_message.png)
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 17, 2014
06:18 AM
I'm beginning to suspect a bug here - i.e. calling a 'click' event for a button on a secondary window. Events just don't get triggered.
I've even tried to trigger a call to a function in a custom DLL when say the Cancel button is clicked. As for a custom action its not called when used in a secondary window scenario. Works fine though when attaching a custom action to a Cancel button on a wizard page.
I've even tried to trigger a call to a function in a custom DLL when say the Cancel button is clicked. As for a custom action its not called when used in a secondary window scenario. Works fine though when attaching a custom action to a Cancel button on a wizard page.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 17, 2014
08:36 AM
We're going to have to dive further into this. I can reproduce what you're reporting, and it actually matches a report we got at the tail end of our most recent beta. I don't think this is new behavior, as the underlying code looks pretty much original, but the timing of the reports suggests that it could be. Behind the scenes, what's happening is if you name a control after one of the predefined IDs (including IDOK, IDCANCEL, IDCLOSE, IDRETRY, IDIGNORE), it is assigned a special ID. This special ID does two things. First, the ID causes clicking that button to close the window. Second, since it closed the window, it no longer processes any actions on that button.
We'll need to change this in code as there are no obvious ways to work around this. (The closest I can come up with is to overlap buttons, having one that does the actions, including setting properties that make the other visible, requiring the user to click again to close the secondary window. And that's clearly not acceptable.) What we'll have to decide, however, is which approach to take:[LIST=1]
Keep the special ID closes the window approach, but run the click event first, and perhaps add a Cancel action to offer a way to cancel the close.
Ditch the special ID closes the window approach; instead offer a Close Window action that lets you specify the ID.
The advantage of the first is that there's less upgrade work necessary, and we might even be able preview this in a hot fix. The second would require a significant upgrader step to give any existing special-ID buttons a Close Window action with the proper ID. Because of the upgrade step, it's much harder to release this approach as a hot fix, even though I like how explicit it is about what it's doing.
Do you have any thoughts on which approach you would find more useful? For instance, do you foresee needing to cancel a window close after a button has been clicked? (I could imagine a case that validates input and wants to show an error message instead of closing.)
We'll need to change this in code as there are no obvious ways to work around this. (The closest I can come up with is to overlap buttons, having one that does the actions, including setting properties that make the other visible, requiring the user to click again to close the secondary window. And that's clearly not acceptable.) What we'll have to decide, however, is which approach to take:[LIST=1]
The advantage of the first is that there's less upgrade work necessary, and we might even be able preview this in a hot fix. The second would require a significant upgrader step to give any existing special-ID buttons a Close Window action with the proper ID. Because of the upgrade step, it's much harder to release this approach as a hot fix, even though I like how explicit it is about what it's doing.
Do you have any thoughts on which approach you would find more useful? For instance, do you foresee needing to cancel a window close after a button has been clicked? (I could imagine a case that validates input and wants to show an error message instead of closing.)
![](/skins/images/CC38E504FC9E1309DC48ACFEB4925670/responsive_peak/images/icon_anonymous_message.png)
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 17, 2014
09:01 AM
Hi Michael!
I had just reached the same conclusion about the 'special ID' buttons. If I change the name of the button to something non-special then all my custom actions work as expected - but the secondary window doesn't close.
I think it would be fine to just modify the behaviour of the special buttons to simply trigger the defined events before automatically closing the window, i.e. your option 1. However do you mean "add a Cancel action to offer a way to cancel the close" that the auto close could be optionally disabled as well?
I had just reached the same conclusion about the 'special ID' buttons. If I change the name of the button to something non-special then all my custom actions work as expected - but the secondary window doesn't close.
I think it would be fine to just modify the behaviour of the special buttons to simply trigger the defined events before automatically closing the window, i.e. your option 1. However do you mean "add a Cancel action to offer a way to cancel the close" that the auto close could be optionally disabled as well?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 16, 2016
11:46 AM
I know this is an old thread but was this issue ever addressed?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 23, 2016
10:00 AM
We have fixed this for InstallShield 2016. We had to rework things internally, so we were unable to address it in InstallShield 2014.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 28, 2017
08:10 AM
MichaelU wrote:
We have fixed this for InstallShield 2016. We had to rework things internally, so we were unable to address it in InstallShield 2014.
I dont think its fixed. I am using IS2016SP1 and still my secondary window doesnt exit after clicking Yes or No button. It simply stays on the main screen,BUT the navigation takes place behind it.
More details on my problem is in this thread:
https://community.flexerasoftware.com/showthread.php?223093-Problem-with-Yes-No-button-in-Secondary-Window-Suite-Installer&p=515544#post515544
If you know the soln plz help.
Thanks
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 28, 2017
08:44 AM
Do you have a 'Close Window' event on the click?
https://community.flexerasoftware.com/showthread.php?223093-Problem-with-Yes-No-button-in-Secondary-Window-Suite-Installer/page2
https://community.flexerasoftware.com/showthread.php?223093-Problem-with-Yes-No-button-in-Secondary-Window-Suite-Installer/page2
![](/skins/images/CC38E504FC9E1309DC48ACFEB4925670/responsive_peak/images/icon_anonymous_message.png)