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?
