Community Forums
Page 1 of 2 12 LastLast
Results 1 to 5 of 8

Thread: Can't get Ok/Cancel buttons on a suite secondary window to trigger a "suite action"

  1. #1
    Join Date
    Oct 2006
    Location
    Stroud, Glos. U.K
    Posts
    165

    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.

  2. #2
    Join Date
    Oct 2006
    Location
    Stroud, Glos. U.K
    Posts
    165
    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.

  3. #3
    MichaelU's Avatar
    MichaelU is offline InstallShield Software Engineer
    Join Date
    Jan 2004
    Location
    Schaumburg, IL
    Posts
    4,683
    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:
    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.
    2. 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.)
    Michael Urman - Staff Software Engineer - Flexera Software: InstallShield Team

  4. #4
    Join Date
    Oct 2006
    Location
    Stroud, Glos. U.K
    Posts
    165
    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?

  5. #5
    Join Date
    Jul 2016
    Posts
    2
    I know this is an old thread but was this issue ever addressed?

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •