Forum Discussion

alinder's avatar
alinder
Contributor
14 years ago

WaitAliasChild failure returns exception, not a stub object.

My TestComplete project has connections to some external systems. We want to be able to select objects based on some partial information about the mapped alias: the alias name of the specific object and the alias name of one of its ancestors.



Example:

The object Aliases.Alpha.Beta.Delta.Epsilon can be identified by the external system as (Beta, Epsilon), or (Delta, Epsilon).



The initial approach was to use FindChild twice, using the MappedName property, but we are finding this gives very poor performance, between 4 to 8 seconds to return every object. This doesn't scale to our needs well.



WaitAliasChild appears to return results much faster, so seems preferable when applicable (as in when finding object Epsilon from object Delta).



The problem I encountered is that if the value of parameter ChildName is not mapped in the Aliases tree as a child of TestObj, an exception is raised instead of the Result returning the empty stub object that indicates the failure.



For example, if object Aliases.Alpha.Beta.Delta.Epsilon is displayed on screen, the command Aliases.Alpha.WaitAliasChild(Delta,0) generates an exception.



The normal case (Aliases.Alpha.WaitAliasChild(Beta,0)) works as expected. 



I also believe normal failure case (Aliases.Alpha.WaitAliasChild(Beta,0) when Beta does not currently exist in the tested app) properly returns the stub object.



My solution has been to check with IsSupported before calling WaitAliasChild, and if not, use FindChild, like this:

If aqObject.IsSupported(Aliases.Alpha,Epsilon) Then

    Set obj1 = Aliases.Alpha.WaitAliasChild(Epsilon,0)

    If obj1.Exists = False Then

        Set obj1 = NameMapping.Sys.FindChild("MappedName","Aliases*" & Epsilon,100,True)

    End If

Else

    Set obj1 = NameMapping.Sys.FindChild("MappedName","Aliases*" & Epsilon,100,True)

End If

5 Replies


  • Hi Andrew,





    The WaitAliasChild function is supposed to be used to check the existence of a mapped object in the Objects tree. If the mapped object is not in the objects tree, the function returns a stub object. But if there is no such mapped object in the Name Mapping tree, this situation is considered as an error in the test, and hence an exception is thrown. So, using IsSupported is the correct approach to avoid the exception.
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    Actually, because of what you are looking for, FindChild, FindChildren, FindAllChildren is better than WaitAliasChild.  The reason being is that WaitAliasChild does not search the whole tree of descendant objects.  So, when you have Aliases.Alpha.Beta.Gamma.Delta.Epsilon and call Aliases.Alpha.WaitAliasChild(), the only valid "child" to wait for is Beta.  Gamma is not a direct child of Alpha so it is not a valid child for WaitAlias child.  FindChild, FindChildren, FindAllChildren actually have a parameter for you to indicate "depth" as to how deep in the tree of child objects you'll search for the one you want. So, I'd not even bother with the check on WaitAliasChild but go directly for FindChild.


  • Thanks for the reply, Robert, but as I mentioned, FindChild does not give sufficient performance for my needs.



    The alternative code I posted is approximately 10x faster given the structure of the application under test on the case we benchmarked.
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    Have you tried FindChild or FindChildren using something other than MappedName?  The reason being is that MappedName has to recurse back into NameMapping/Aliases to find the name and you're already calling within NameMapping/Aliases.  If you use a different property or, even, an array of properties, that might give you better performance on FindChild.
  • Another property isn't really an option unless the alias name is reflected in another property I haven't found.



    The mapped name is known, defined for every mapped object, and unique amongst like descendants, hence why we're using it. We could have created a more comprehensive structure for this, but then we'd be re-implementing the Name Mapping.