Forum Discussion
Hi,
> Aliases.browser.pageMain.wndWindowContent.WaitAliasChild("panLogin", ProjectSuite.Variables.TinyWaitTimeout);
> wndWindowContent is present. This is a very top level element [...]
This might be the reason depending how panLogin alias is mapped.
Guessing that if it is mapped using Advanced Find, then TestComplete will drill-down complete objects tree in order to check if the sought for alias exists.
The more definite and precise identification criteria and search path are defined in NameMapping, the more fast .WaitXXX() method will work.
So I am guessing by Advanced Find you mean extended search? It WAS using extended search. And it did not need to. I removed the selection of extended search on wndWindowContent. I confirm that it is still found properly. That element is used all over the place and does not take a long time to find. panLogin, when present, is found immediately. When NOT present, the timeout is not being honored. That is the crux of my issue.
Thanks
- vthomeschoolmom5 years agoSuper Contributor
I replaced the WaitAliasChild with FindChild and properties. It is much faster. Still kinda wonder why WaitAliasChild is taking so long. I want it to timeout when I want it to! I don't love the FindChild in this case since it mimimizes the effectiveness of reuse of a well constructed NameMapping. Ah well. Such is life.
- tristaanogre5 years agoEsteemed Contributor
Can you screenshot your NameMapping of the relevant section, making sure you expand to show the "Extended Find" column? Also, a bit more of your workflow/automation in a screenshot would be helpful. Obviously, there's a reason why you're waiting at that point... but I wonder if there might be something else that needs to be considered. If this is a web page, there could be other Active components and loads and things that are happening that calling WaitAliasChild at that point is causing other things to trigger.
This could also be a caching thing. Have you tried calling "RefreshNameMapping" on the parent object before you call WaitAliasChild?- vthomeschoolmom5 years agoSuper Contributor
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.
Related Content
- 6 years agorizzomeister