Although Runtime Loader is an easy-to-use tool that allows running Flash and Flex applications which are not prepared for automated testing in a special way and that makes them testable at run time, there are some known limitations on testing applications with Runtime Loader.

Sometimes, a Flash (or Flex) application and its wrapper web page may extensively interact and exchange data between each other. Runtime Loader can load only a .SWF file in which a Flash (Flex) application is implemented. The wrapper web page into which the application is embedded is not loaded by the Loader. Therefore, you cannot test such an application properly by using Runtime Loader. In this case, you should either use the debug version of Flash Player to test your application or you can recompile your application with the TestComplete FlexClient helper library or with Microsoft Active Accessibility support enabled and test the application along with its wrapper web page without using Runtime Loader.
Runtime Loader loads a Flash (or Flex) application’s .SWF module by using the SWFLoader Flex control. When the application is loaded into this control, the Runtime Loader application with its SWFLoader control becomes the parent application of the loaded one. So, Runtime Loader and the loaded application compose a new application object hierarchy. If the loaded application was created without taking into account the fact that the application may be loaded by a SWFLoader control, such an application might work incorrectly when it is loaded into Runtime Loader.

For instance, a child form of the tested application’s main form may refer to the top-level mx.Core.Application object via the mx.core.Application.application or mx.core.FlexGlobals.topLevelApplication property. In this way, child application forms may obtain or change values of some user-defined properties of the object that corresponds to the main application form. However, if the application is loaded into Runtime Loader by the SWFLoader control, the Runtime Loader application becomes a top-level application for the loaded one. The mx.core.Application.application and mx.core.FlexGlobals.topLevelApplication properties called from code in the loaded application will refer then to the mx.Core.Application object of Runtime Loader instead of the mx.Core.Application object of the loaded application. So, the needed user-defined properties of the mx.Core.Application object in the tested application will not be accessible via the mx.core.Application.application or mx.core.FlexGlobals.topLevelApplication property and any attempt to access these properties in this way will cause exceptions.

To overcome this situation and make the tested application compatible with Runtime Loader, the developers need to modify the application’s source code. For instance, the problem can be solved in the following ways:
- By referring to the parent application via the moduleFactory["application"] property.
- By using another approach for exchanging data between the application modules (for instance, interfaces).
If code modifications are impossible, then, instead of using Runtime Loader, run the application in the debug version of the Adobe Flash Player with the FlashInjector helper module preloaded or compile the application with the TestComplete FlexClient library.
When running your application from Runtime Loader, make sure that the application was compiled without the TestComplete FlexClient library (see Preparing Flash and Flex Applications for Testing with the FlexClient Library). The Loader already contains this library and applies its functionality to the loaded .SWF module of the tested application. We do not recommend that you use Runtime Loader to run applications compiled with the FlexClient library, since this may cause errors.

Limitations on Testing with the Runtime Loader Utility

See Also