I'm looking for potential culprits so I can file a well documented bug report. This is only happening with AIR 1.1 it seems, and my AIR app is the only one I'm seeing it on. The keystrokes and menus are firing the correct events, but currently open windows are not being closed as the docs say. They claim in OS X when quit is selected from the application menu or the dock menu, the EXITING event will be dispatched and all windows will be closed as long as noone prevents the default behavior. Well that event is being dispatched, I'm tracing it to make sure I caught it, not doing anything else with it, and my windows just sit there still open on the screen.
What I'm doing as as workaround in the meantime is catching the event and then manually calling close() on all the open windows, I have autoExit enabled so this restores the desired behavior of exiting the application. On Wed, Jul 2, 2008 at 9:18 AM, Simon Bailey <[EMAIL PROTECTED]> wrote: > I hate to state a potential obvious one here but have you got Num Lock > on, this I remember prevents using short cut keys? > > Cheers, > > Simon > > On 2 Jul 2008, at 15:04, valdhor wrote: > > Maybe you can add an event listener to the stage and look at > keystrokes. If someone presses Apple-Q, dispatch a click event to the > close box of the main window. > > --- In [email protected] <flexcoders%40yahoogroups.com>, "Daniel > Gold" <[EMAIL PROTECTED]> wrote: > > > > AIR updated itself this morning, and now it seems I can no longer > quit an > > app I'm developing using Apple-Q on my Mac or by choosing "Quit" > from the > > Dock/Menu bar. It is quite possible something in my code broke this > but I > > haven't found any likely culprits yet. > > > > Has anyone seen an issue like this in AIR? Choosing quit will close > one of > > my growl-like notification windows if they're up, but my main window and > > toolbar just sit there, I have to force quit the app. > > > > >
