Even generating shim classes would result in conflicts if you have more than 
one definition of a class you are trying to "shim" into the main 
applicationdomain.

But if you can guarantee there isn't conflicts for a particular test scenario, 
then maybe you can test by loading into the main app domain.

From: Nigel Magnay <nigel.mag...@gmail.com<mailto:nigel.mag...@gmail.com>>
Reply-To: "flexcoders@yahoogroups.com<mailto:flexcoders@yahoogroups.com>" 
<flexcoders@yahoogroups.com<mailto:flexcoders@yahoogroups.com>>
Date: Tuesday, October 1, 2013 4:38 AM
To: "flexcoders@yahoogroups.com<mailto:flexcoders@yahoogroups.com>" 
<flexcoders@yahoogroups.com<mailto:flexcoders@yahoogroups.com>>
Subject: Re: [flexcoders] Automation and Application Domains



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<mailto: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<mailto:nigel.mag...@gmail.com>>
Reply-To: "flexcoders@yahoogroups.com<mailto:flexcoders@yahoogroups.com>" 
<flexcoders@yahoogroups.com<mailto:flexcoders@yahoogroups.com>>
Date: Friday, September 27, 2013 6:36 AM
To: "flexcoders@yahoogroups.com<mailto:flexcoders@yahoogroups.com>" 
<flexcoders@yahoogroups.com<mailto: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?




Reply via email to