Convert FindChild object to NameMapping object

[jpruddick]

Hi all,

I've been running into a problem in my code in which I need to find any object that fits certain properties- not a specific object, but just the first one that matches the criteria- and then continue to reference the object initially found even if it's recreated by the system or its original identifying properties change. I can do the first part quite easily with Find and FindChild, but the second is giving me trouble.

My current idea is to map all the objects that might fit the initial criteria with NameMapping. Then I can have my test initially locate an object with FindChild, but later reference it using NameMapping. However, it seems as though there is some invisible difference between the object variables produced by FindChild and those produced by NameMapping. Furthermore, I can't find any way to take an object variable produced by FindChild, and either convert it to rely on NameMapping instead, or create a new variable referencing the same object using NameMapping.

Does anyone have any idea how to convert from a FindChild-located variable to a NameMapping one? Thanks in advance for any help you can offer.

[tristaanogre · Accepted solution]

You can't, not in code.  NameMapping is an object repository configured and created in design time to identifiy components.  Once it's been mapped, the objects then can be refernenced in code using Aliases.

FindChild and find methods are dynamic runtime methods for finding and identifying objects.  You cannot convert that into the NameMapping because the NameMapping is not written to at runtime but only read from.

What I would do is that, once you've found the object, persist it in a variable that is globally available.  However, if the object is destroyed in memory and recreated, anything stored in that variable will no longer be available.  So, you would need to find it again.  If it's such a dynamic object, that will probably be your best bet.

[jpruddick]

Thanks for the response! I'll admit I'm still a bit confused, though. As far as I know, switching to a NameMapping reference for an object that's already been mapped should only require reading the NameMapping repository, not writing to it. Is this not the case?

Also, when you say "destroyed in memory", does that refer to TestComplete's memory, or the tested application's? The problem I'm currently trying to solve is that TestComplete loses track of the object when it is recreated within the tested application, so if you are referring to the tested application's memory, I'm not sure global variables would solve my problem.

[tristaanogre]

Correct, if the object has already been mapped you shouldn't even need to use the FindChild method at all.  But you mentioned changing an object found by FindChild into a Mapped object... that's not possible.  But if it's already mapped... then you don't really need FindChild at all... you just need to using something like WaitAlias or WaitChild.

As for detroyed in memory, I mean the memory of the system... the object has a handle in memory that if it's destroyed and recreated, that handle changes.  FindChild actually returns the object handle... and if it is destroyed and recreated, you lose that handle.  Using Aliases/NameMapping always searches for the object so it will always return the latest version.

[jpruddick]

I see. Many thanks for the clarification; I hadn't realized that was how FindChild worked!

Unfortunately, it doesn't look like WaitChild or WaitAlias will work for me. The object I need to reference may be one of several pre-mapped objects based on other factors in the test; that's why I was using FindChild, the results of which can change based on its parameter inputs. WaitChild and WaitAlias only have a depth of 1, and must search for specific object names, when I don't actually know in advance which object I'll need to reference.

[tristaanogre]

So, if the objects are pre-mapped, then you can use WaitAlias child.  As you mentioned, the existance of the object is predicated on other conditions.  I'm assuming that those other conditions are known and you can make checks on that.  So, you could write (pseudo code) something like this:

var objectINeed;

switch Condition of
Condition1: objectINeed = Aliases.myApp.parentObject.WaitAliasChild('ChildName', 10000);
break;
Condition2: objectINeed = Aliases.myApp.otherParentObject.WaitAliasChild('DifferentChildName', 10000);
break;

objectINeed.Action();

There's no need to use FindChild at all.  That's the thing about automated tests, you are in control of the conditions and, therefore, can code the decisions of what to do.