Yes, it seems to fail. RIAtest has a component 'inspector', which shows the component tree. If my UI component is in a different (child) application domain, it never appears in the inspector (and events from manipulating it never get received).
When I raised a ticket against it (and asked if there were some API that I could use to perhaps inform it more directly to my new application domains), they pointed me to the supposed flex automation restriction - hence me starting to dig to see if I might be able to overcome the restriction - perhaps by generating shim classes or delegates.. On Fri, Sep 27, 2013 at 7:25 PM, Alex Harui <aha...@adobe.com> wrote: > ** > > > Did you actually try it and found that it fails? I would think it should > be able to introspect child appdomains. > > From: Nigel Magnay <nigel.mag...@gmail.com> > Reply-To: "flexcoders@yahoogroups.com" <flexcoders@yahoogroups.com> > Date: Friday, September 27, 2013 6:36 AM > To: "flexcoders@yahoogroups.com" <flexcoders@yahoogroups.com> > Subject: [flexcoders] Automation and Application Domains > > > > We are using RIAtest, which uses flex automation to test some applications. > > Reading the flex documentation, it contains the following: > > Testing applications that load external libraries > > ... A library that is loaded at run time (including run-time shared > libraries (RSLs)) must be loaded into the ApplicationDomain of the loading > application. If the SWF file used in the application is loaded in a > different application domain, automated testing record and playback will > not function properly. > > > This is particularly inconvenient for us; we load UI controls into > separate ApplicationDomains (all children of > ApplicationDomain.currentDomain) because they can have conflicting > classnames, and this allows each form to be generated in isolation, and > they cannot interfere with each other. The thought of having to refactor > hundreds of classes is not appealing. > > > This seems to prevent RIAtest's inspector from finding child controls > sourced from that loader. > > Is there any way around this restriction, perhaps by implementing some > kind of delegate class, or overriding the automation provider to allow it > to callback to discover the applicationdomains it needs to search? > > >
