Forum Discussion

Antonio_Haynes's avatar
10 years ago

Help! lightweight find method for flex/flash application needed.

 I have implimented a basic find method to locate objects in my tested application. 

Method Below:


function Get_Control(PropName, PropVal){
 //Creates arrays of property names and values
 propArray = PropName.split(",");
 valuesArray = PropVal.split(",");

 // Searches for the control
 var p = Project.Variables.Process;
 // Depth at 1000 because we do not know where the control might be.
 Project.Variables.Control = p.Find(propArray, valuesArray, 1000);

 // Processes the search results
 if (Project.Variables.Control.Exists){
   Log.Message("Failed to Identify an object by the property value specified.", PropName + " " + PropVal)
   Log.Error("The object was not found.");
   Project.Variables.MoveToNextStep = true;


This method works woderfully when i am in the login screen of my application wich has maybe 20 controls to sort through.
However once logged into my application there are thousands of controls to sort through and i have seen up to 3 minute wait times before a control is found, if i am lucky.
One other thing that happens when trying to find a control using this method, there is a constant growth in memory usage on my machine between my browser and Test Complete. I have tried finding ways to disable caching of objects during playback and set my name mapping to Do not store Code Completion data, wich helped a little on the memory usage.
I am running Windows 7 64bit OS with 6GB ram and after disabling store code completion data, im left with about 50 mb ram by the time my control is found now.
Test Complete runs at about 200,000 kb ram during normal use and my Fire fox is about 250,000kb during normal use with TC.
I have watch these processes reach the millions while executing the find operation and even crashed TC a few times.

I hope to use a method like this to find the control I intend to work with, but taking anything more than a few seconds to find a control is not acceptable when there may be hundreds of controls needed in a single test.
Please help me on this, I need something fast and lightwieght enough to not max my proccessor.
This method is the heart of my project, if i can't effectivly find my controls, then i don't have anything to work with.
I would also like to avoid name mapping as our developers do daily releases and while the properties of the controls users can see on the page don't normally change, we see alot of containers and wrappers that are dynamically generated and even some containers that do not exist between browsers. Name mapping for this particular test environment has created a nightmare for my team and become more work than i feel we can keep up with, this project is an attempt to resovle some of those issues.

The tested application I am working with is a flex/flash application and my tests must be able to execute against IE, FireFox, and Chrome.

Thanks, and feel free to ask for more information if i've left something out.

  • Antonio_Haynes's avatar
    10 years ago

    Just to follow up with this thread using the browser.find method is working great for me now .... i have managed to remove the name mapping and the tested applications from my project entirely after wich i no longer have any issue with memory i find my controls based on property name/value pairs and im able to pass any process as a tested process and then begin mapping controls using my methods this has opened a great platform for creating automated tests against any platform. I'm in no way trying to play down the name mapping and tested applications included with test complete but i find that this method is much more suitable to automating in my current environment. Thanks for the input in helping me toward my solution!

17 Replies

  • AlexKaras's avatar
    Champion Level 3

    Hi Antonio,


    You are searching for the control from the Process root. Any real reason to force TestComplete to traverse the whole objects tree? My preference in this case is to start search as close to the expected control's location as possible. I.e. if you expect control to be on some specific window - start search from this window, if the control is on some tabbed panel - start search from there. To say the truth, I can hardly imagine the test case that says something like "search for the SSN control throughout the application and populate it with the patient's SSN". More likely is that the test says "while on the Patient Properties form, enter patient's SSN into the SSN field". So searching for the SSN control from the Patient Properties root you'll get two benefits: a) the search will be faster; and b) if the control is not found this will let you know that something changed in the form's design and this might be a problem worth to be reported.

    • Antonio_Haynes's avatar

       yes your solution is exactly what i plan to do, although im am trying to build an excuting script using test complete and run my steps off of an excel file. So i want to stay away from using name mapped items inside the project. I need to be able to hand a parent control using a column in my xls to help narrow the search. Unfortunalty I can think of a number of ways that this could cause issues in playback. So any tips and tricks i can use would be helpful.
      In order to call the parent object without a name mapping I think i'm going to have to use the full name of the control.
      I'm not sure off the top of my head if i am able to use wildcards in the full name of an object in test complete, if i can that would help keep scripts from breaking when something in the full name has changed.


      so my executing script might look something like


      minus the hard coded string :)

      var parent = Project.Variable.Process + Project.Variable.TestItem("Parent Object Full Name Minus Sys.Browser().Page()");

      parent.Find(propNameArray, propValArray, depth);


      currently my process name is built off the browser and evironment of my tested application specified to test against 
      so it looks like 



      so i guess the question now is would something like this work when refrencing the full name of the parent.

      I hope that makes sense :p sorry its been a long day already.


  • Ryan_Moran's avatar
    Valued Contributor


    ....that is exactly what Antonio already said.



    I was able to improve performance a least in my tests this returns in about 1/4 the time.



    function main() {
    var wshell = new ActiveXObject('WScript.Shell');
    var start = new Date().getTime();
    var parent = //your parent object
    mychild = findobject(parent,"Name",".*yourcontrolname.*",5000);
    wshell.popup("Time executed: " + (((new Date().getTime() - start) / 1000)) + "\nFound object: " + mychild.exists);
    function findobject(parentObject,propArray,valuesArray,depth) {
    propArray = propArray.split(",");
    valuesArray = valuesArray.split(",");
      just checking all visible controls
    var VOSArray = parentObject.FindAll(["Visible"],[true],depth,false).toArray();
    var tmpObj = matchproperty(VOSArray, propArray, valuesArray,depth);
    return tmpObj;



    • Antonio_Haynes's avatar

       Awesome! I'm Going to try this right now XD
       Thanks, Its much cleaner this time to.

      • Ryan_Moran's avatar
        Valued Contributor

        Sure, just note I did not include the second matchproperty function because I made no changes to that. :)

  • I went ahead and took the liberty to record a jing of my recource monitor when running this test.
    The test is a simple log in and then one object trying to be found and clicked once logged in.
    I felt it may be important to share this info in the scenario this may be a bug or something someone knows how to fix.


    • Antonio_Haynes's avatar

      Please any help would be very much appreciated, I would like to add that when the object does not exist on the page the find fails in no time flat but if the object does exeist that is when i recieve the long wait time.

      • jorgesimoes1983's avatar
        Regular Contributor

        We had a similar experience with flash/flex automation. We reached the conclusion it was because our application had layers inside of layers, inside of layers, inside of layers...


        Eventually we gave up flash automation.