Ask a Question

WaitAliasChild taking way longer than specified timeout to return exists = false

Super Contributor

WaitAliasChild taking way longer than specified timeout to return exists = false

var sessionPresence = Aliases.browser.pageMain.wndWindowContent.WaitAliasChild("panLogin", ProjectSuite.Variables.TinyWaitTimeout); // 0 represents immediate return.


So I have this line of code which is intended to wait for the panel specified by the alias. I then check the Exists property to decide what to do if it is there. TinyWaitTimeout suite variable is set to 200. 


When the panel is present, it is found quickly and the sessionPresence is identified as existing and everything is lovely. If the panel is not present, the code delays for WAAAAAY more than TinyWaitTimeout. I tried


var sessionPresence = Aliases.browser.pageMain.wndWindowContent.WaitAliasChild("panLogin", 0); // 0 represents immediate return.


for giggles and still that line waits for a very long time.


When I set a break point there, and step over the line, the wait is executed perfectly, waits the right amoung of time to give up and return Exists true or false. 


This is going to slow my runtime since this line is executed with every single test in my quite large (and getting larger) suite as it has to do with handling a login gone wrong. While I always prioritize stability over run time speed, this one makes no sense. 


Does anyone have any idea how to make this Wait execute for the correct time out period? Honeslty, I think I am missing something obvious because I use this kind of technique All The Time.





What you say may be true. That the parent object does not exist. What is problematic for me is that if the parent does not exist, then clearly the child does not. What is the point of a timeout value if the seek is not going to ... well... timeout? The documented behavior is what I am seeking here. Look until time x. When time x is reached, stop.

It has to do with the logic of the process.... in order to call the WaitAliasChild method of the parent, it needs to detect that the parent is present.  Since you don't have a coded "Wait" for the parent, it uses the default wait time for the overall project for the parent before it can call the WaitAliasChild.  The way the logic works, when you write


Aliases.MyApp.Parent.WaitAliasChild('Child', 10000)


TestComplete checks each part of the tree from top down... first checks MyApp, then Parent, then it can call WaitAliasChild.  The assumption made is that you've already done the necessary checks for MyApp and Parent so any attempts to access them goes back to that default timeout.


Probably, the MOST correct way of doing this is..


myProcess = Sys.WaitProcess('MyApp', 10000)

if myProcess.Exists then

myParent = Aliass.MyApp.WaitAliasChild('Parent', 10000)

if myParent.Exists then

myChild = Aliases.MyApp.Parent.WaitAliasChild('Child', 10000)


BUT... that gets bulky so folks usually shortcut places where you already KNOW that an object exists.


Since in your case the parent is not guarenteed to exist at the time you're checking, that should be your first check.

Robert Martin
[Hall of Fame]
Please consider giving a Kudo if I write good stuff

Why automate?  I do automated testing because there's only so much a human being can do and remain healthy.  Sleep is a requirement.  So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.

Mysterious Gremlin Master
Vegas Thrill Rider
Extensions available



Robert's explanation is correct.

The only point for this part:

> Aliases.MyApp.Parent.WaitAliasChild('Child', 10000)

> TestComplete checks each part of the tree from top down [...]

Must be read as "TestComplete checks each part of the *NameMapping* tree from top down [...]"

Remember what has been said above: Aliases tree is the custom, stable and convenient to you, logical representation of the UI. This logical representation is mapped to the real physical layout via the translation NameMapping table.

So, when you command TestComplete to wait for some alias, TestComplete finds the alias, maps it to the object from the NameMapping table, traverses to the root object in NameMapping (Sys or Mobile) and starts navigating down the tree path searching for the relevant object and waiting for it if this current object is absent at the moment. As this object is sought for internally, TestComplete has no information as for whether this object must be already present or may appear within the generic (project-wide) timeout. Thus, TestComplete waits using the default project timeout. When TestComplete reaches the final target object (the one with the specified alias name), then TestComplete uses the timeout explicitly specified in test code.

Does this make sense?


  /Alex [Community Hero]
[Community Heroes] are not employed by SmartBear Software but
are just volunteers who have some experience with the tools by SmartBear Software
and a desire to help others. Posts made by [Community Heroes]
may differ from the official policies of SmartBear Software and should be treated
as the own private opinion of their authors and under no circumstances as an
official answer from SmartBear Software.
The [Community Hero] signature is used with permission by SmartBear Software.
SmartBear Alumni (Retired)

Thanks everybody for the help!

@vthomeschoolmom, does the suggestions given here help you resolve the issue?



Tanya Yatskovskaya
SmartBear Community and Education Manager

Showing results for 
Search instead for 
Did you mean: