cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Not applicable

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.
Labels (1)
0 Kudos
(7) Replies
Not applicable

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.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

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.)
  • 0 Kudos
    Not applicable

    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?
    0 Kudos
    FrankZ
    Level 2

    I know this is an old thread but was this issue ever addressed?
    0 Kudos
    MichaelU
    Level 12 Flexeran
    Level 12 Flexeran

    We have fixed this for InstallShield 2016. We had to rework things internally, so we were unable to address it in InstallShield 2014.
    0 Kudos
    dinesh_redhawk
    Level 6

    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
    0 Kudos
    rguggisberg
    Level 13

    0 Kudos