Forum Discussion
So this code that I have shown is on the OpenStandard procedure that is used in all the tests. Picture the desired workflow
- Open browser.
- Login.
- Do test stuff.
- Logout.
- Close browser.
Where bolded is the intent of StandardOpen()
If the test that preceeded the current one barfed for whatever reason, the browser is closed without logging out. So the next time login occurs, the page prompts do you want to resume the last session. The standard open then becomes
- Open browser.
- Login.
- If the login panel is present, you are seeing the session resumption prompt. Select to resume previous session.
- Logout ending session
- Login
Aliases.browser.pageMain.wndWindowContent.RefreshMappingInfo(); var sessionPresence = Aliases.browser.pageMain.wndWindowContent.WaitAliasChild("panLogin", ProjectSuite.Variables.TinyWaitTimeout); if (sessionPresence.Exists) { sessionPresencedialog = Aliases.browser.pageMain.wndWindowContent.panLogin.WaitAliasChild("selSession", ProjectSuite.Variables.TinyWaitTimeout); }
The WaitAliasChild here (re-added the code so it might not be precisely the same) is taking a loooooooong time to return the object with the exists stub only when the object does not exist. When it does, it returns right away. All is well.
var propNames = new Array("ObjectType", "ObjectIdentifier"); var propValues = new Array("Panel", "ng_login_container"); var sessionPresence = Aliases.browser.pageMain.wndWindowContent.FindChild(propNames, propValues, 10);
This works well. But, I happen to be in the middle of a big port to our app under test's new UI. One of the reasons it is going super well is that the NameMapping was pretty well organized. So I don't LOVE using Find. But this is not a hill I am going to die on. It really is just one function. That said, I sure would like to know what is going on for my greater understanding.
Hi,
Thank you for the screenshot of your NameMapping/Aliasing.
Aliases is the means to provide you with more convenient and stable logical structure of your tested application's UI. Aliases are based on NameMapping which corresponds to the physical organization of application's UI. (Consider NameMapping as a translation table between physical and logical UI layouts.)
With the above in mind, my current understanding of your problem is this:
-- While aliased name of the sought for control is
Aliases.browser.pageMain.wndWindowContent.panLogin,
the physical layout (from NameMapping) is
Aliases.browser.pageMain.wndWindowContent.panel.panLogin;
-- It is my guess that if panLogin does not exist, its parent panel object does not exist as well;
-- If my guess is correct, then, when you ask TestComplete to wait for the panLogin aliased object, TestComplete internally first looks for the panel object. And if this object does not exist, then TestComplete waits for it using default project timeout.
I hope that this is the reason of the delay you are observing.
As a way to speed things up, you may try to add a panel object from NameMapping as another Aliased element and put it on the same level as panLogin one (in order to keep your existing code unchanged). For better usability you may rename the alias for this panel to, say, panLoginPanel.
Then, change your code line to this:
var sessionPresence = Aliases.browser.pageMain.wndWindowContent.WaitAliasChild("panLoginPanel", ProjectSuite.Variables.TinyWaitTimeout);
and keep the rest of your code as it is.
Does this help?
- tristaanogre5 years agoEsteemed Contributor
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.
- AlexKaras5 years agoChampion Level 3
Hi,
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?
- vthomeschoolmom5 years agoSuper Contributor
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.
Related Content
- 6 years agorizzomeister
- 8 months agoSjef
Recent Discussions
- 2 days agovladd1