5 Replies Latest reply on Aug 15, 2013 10:57 AM by bob_baldwin

    Escape Key Eaten In EB2.1 CC InDesign

    bob_baldwin Level 1

      Most Flex people are already familiar with the wonky behavior around escape key detection -- if you want to eat the keyboard event to do something prior to closing a window, for instance, you just listen for a key down, assess it and do whatever it is you need to do (generally eat the event and close the window through one of your own methods after doing whatever clean up you need to do).

       

      But that's not the way things work in InDesign CC when invoking modal dialogs, and I am stymied on how to address the issue:

       

      When a user opens a modal and subsequently presses the escape key, the key down event it is NEVER passed to any listener -- either stage, application, native application, window or currently focused component. Behind the scenes, CC's Flex implementation simply closes the open dialog but the Window instance and its wrappered NativeWindow instance essentially are simply hidden rather than removed from the display list (so you can't listen for a removed from stage event) so they're just hanging around biding their time.

       

      The ugly aspect of this, of course, is that if you are holding on to any references to any window anywhere, the instances of both the Window and the NativeWindow are never garbage collected. Soon, bye-bye ID.

       

      I've been trying to find some way to interact with this special case of the window close process over the last hour or so through overrides, event listeners, bindings, etc., etc. -- the only way to infer the window is closing is by listening for a window deactivate event, but the window is still visible when deactivate is called so there's no way to know a close has occurred rather than, for instance, an application deactivate.

       

      Has anybody out there solved this problem?

        • 1. Re: Escape Key Eaten In EB2.1 CC InDesign
          Harbs. Adobe Community Professional & MVP

          Can you listen for a hide event?

          • 2. Re: Escape Key Eaten In EB2.1 CC InDesign
            bob_baldwin Level 1

            No. Attaching a listener for that event to the modal window does not work -- it's never dispatched to the listener. It's a fairly ugly issue. The way I've kludged it for now is to create a window queue that, when populated, activates a timer. The timer sweeps the queue looking for native windows that are no longer visible then invokes close on the Flex wrapper object.

             

            But it's even more complicated than that, of course, because, as you might expect, certain cancel button click handlers have to perform clean-up ops and so forth...so in an even uglier kludge, the swept window is introspected for cancel buttons and then an artificial click event is sent to the button. Ugh...let me know if you have any other insight, but thanks for the response.

             

            Clearly the best solution would be to let the plug in window receive the key down event.

            • 3. Re: Escape Key Eaten In EB2.1 CC InDesign
              Harbs. Adobe Community Professional & MVP

              No much different than your "solution", but you can create your own window manager. When you open a window, you register it with the manager, which in turn checks to see if it closes.

               

              Probably a better way to do it would be to start a timer when the modal window opens that checks every second or so if the window is visible. If not, it could call you close() method. That way a window would be responsible to close itself...

               

              Harbs

              1 person found this helpful
              • 4. Re: Escape Key Eaten In EB2.1 CC InDesign
                Harbs. Adobe Community Professional & MVP

                Either way, it's good to know about this issue, because I'm probably going to have to work around it myself...

                • 5. Re: Escape Key Eaten In EB2.1 CC InDesign
                  bob_baldwin Level 1

                  Well, I do have a pseudo window manager -- that's the guy responsible for the timer. It maintains an independent queue where windows are "registered" and "unregistered"....but I take your point. I do like your approach better, I just had to get something up and running for an interim release.