Forum Discussion

mfoster711's avatar
mfoster711
Regular Contributor
2 years ago

TestComplete extreme slowdown on FindChild call

I am having an issue with TestComplete taking an extreme amount of time to perform a single FindChild. This issue only occurs when:

  1. The TestComplete .Net Extension is enabled
  2. I have our test application open

Here is the test code I have been using to duplicate this issue and this is what I sent to Smartbear support.

    'When the ".Net Application Support extension" is DISABLED:
    '   - script takes less than 0.25 seconds to run. 

    'When the ".Net Application Support extension" is ENABLED:
    '   - script takes 55 seconds to run with 8 AppSuite Windows open.
    '   - script takes 30 seconds to run with 4 AppSuite Windows open.
    '   - script takes 12 seconds to run with 1 AppSuite Windows open.
    
    OverallBegin = Timer()

    'This first FindChild is designed to intentionally fail to demostrate time it takes when the window does not exist.
    Begin = Timer()
    Set w = sys.FindChild(Array("Enabled", "WndCaption", "Visible"), Array("True", "*Not Found Window*", "True") , 2, True)
    Log.Message("1 Time: " & FormatNumber(Timer() - Begin, 3) & " Window exists: " & w.Exists)

    Begin = Timer()
    Set w = sys.FindChild(Array("Enabled", "WndCaption", "Visible"), Array("True", "*AppName Window*", "True") , 2, True)
    Log.Message("2 Time: " & FormatNumber(Timer() - Begin, 3) & " Window exists: " & w.Exists)

    Log.Message("Overall Time: " & FormatNumber(Timer() - OverallBegin, 3))

 

The first sys.FindChild line is the line taking longer and longer to process.

 

There is some conflict occurring between TestComplete and our test application and I don't know what to do next. I have been trying to get a resolution from Smartbear support for over a year and have got nowhere. 

 

Does anybody have any clues or suggestions on how to further troubleshoot this?

 

3 Replies

Sort By
  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    2 years ago

    Hi,

     

    Unfortunately, I don't have good ideas at the moment as .FindChild() works fine for us... The only difference is that we never used Sys.FindChild() but <SomeObject>.FindChild().

     

    Another thing that drove my attention was use of strings as values for boolean properties - i.e. "True" as a value for .Visible boolean property. Not sure that this is a source of the problem though...

     

    • mfoster711's avatar
      mfoster711
      Regular Contributor
      2 years ago

      I changed the boolean values to True instead of "True" and that makes no difference.

       

      I normally use <SomeWindow>.FindChild when possible but that is not an option in this case.

       

      Our test application is a robost product that includes dozens of sub-applications. For example: Accounting, Invoicing, Customer, Inventory, etc. are all sub-applications and when you open a sub-application it opens a new process. So, if I need to find the Accounting window I have to use the Sys.Process.Findchild to find the right Window and then I use that object to reference all of the fields in the window. If I tried using the following Sys.Process("AppSuite").FindChild it would only look at the first process and the Accounting window could be any of the multiple processes open.

       

  • mfoster711's avatar
    mfoster711
    Regular Contributor
    2 years ago

    I should expand on my explanation. I think the issue is related to the last parameter on the FindChild call, the "RefreshTree" option.

     

    In my example, the slowdown only occurs when the object is NOT found and this results in a refresh of the namemap to try and find the object.