I'm still hopelessly plugging away at this. I've tried: - profiling the application to gain any insight into the issue - running traces throughout the window to see if it is firing differently
I'm not able to see any differences between the window being instantiated via the receiving localConnection method and it being instantiated within the AIR app directly. The window is being instantiated the exact same way in both circumstances -- logic for launching it is encapsulated in a static method in the window itself. Maybe I'm jumping the gun, but I'm thinking this is a bug in AIR or Flex. I've opened the following report: http://bugs.adobe.com/jira/browse/SDK-23425 Any ideas? Thanks, Mike --- In flexcoders@yahoogroups.com, "michaelisraelcaplan" <mcap...@...> wrote: > > Hi, > > I'm working through a really strange issue with my Flex 4 AIR app. I've lost > days of sleep, hair, and numerous brain cells trying to get to the source of > the issue with no luck. The scenario is as follows: > > - AIR app with initialized receiving and sending localConnection objects. > > - Browser with an initialized receiving and sending localConnection objects. > > - The AIR app receiving localConnection object is triggered by the browser, > resulting in a new instance of a spark window. > > - Form elements in the window (DropDownList in particular) become _slow_. > For example, to open up the dropDownList I need to click and hold for 3-5 > seconds. > > > The reason I believe that this is a issue with the AIR receiving > localConnection is if I open a new instance of the spark window from the AIR > app directly it works fine. As soon as I open a new instance from the > receiving localConnection method, that instance slows. Also, any future > instances opened (from the AIR app directly) are also slow until I restart > the application. > > I'm looking for some tips on how to solve this issue. Or, if you have ideas > how I can better troubleshoot this, that would be great too. > > Thanks, > > Mike >
