Hello,
Thanks for the reply.
- If I add a wait time I get the same results: unable to find object. The screenshot associated to this step, however, shows clearly the element (a button)
- The error message is unable to find element
- It is a static element. It does not change and there is no other element with the same properties that can 'confuse' TC. It is simply a button that when clicked shows a new (static) form.
- The failure occurs always at the same element.
I have been able to bypass this problem changing the way the element is identified
Hi,
It is good to know that you've managed to solve the problem.
Several notes:
-- As TestComplete can identify the button using 'div' syntax, for me it sounds like that the original locator does not work anymore. Use browser's Developer Tools or TestComplete's Object Browser to double check that the button still can be identified as "//input[@value='Add Standard User']". Note possible leading/trailing white characters.
-- I am not XPath expert and I think that the search line like this (FindElement("//iframe[@id='Teams']").FindElement("//input[@value='Add Standard User']")) will work (almost?) in all cases, but I think that it is not optimal in terms of performance as it searches for every element from the root of DOM model. My preference is to search not from the root, but from the parent container object. I.e.: FindElement("//iframe[@id='Teams']").FindElement(".//input[@value='Add Standard User']"). Note the dot before //input. Though this note is just for the record.
> It is a static element. [...] shows a new (static) form.
Please define what is 'static' in this case. Web element can be considered to be static only if it is obtained from the server within page source and constantly exists in page markup. It may be visible or not but it must exist and must be not (re)created via script. If the element is downloaded asynchronously and then inserted into DOM or generated via script, then such element is dynamic. Even if it has the same id every time it is (re)generated. In such case you are just lucky because you are dealing with the application that was created with testability in mind.
> The screenshot associated to this step, however, shows clearly the element (a button)
Error message is of higher priority and level of trust. Just because it takes some time to take a screenshot and post error message to test log when the element is not found. And the time it takes might be enough for the element to be inserted in the DOM and to be rendered on screen.
The bottom line:
If the element cannot be found this is usually because of either incorrect/changed locator or the element to be dynamic and TestComplete is not instructed to wait for it.
P.S. I would also recommend to read this my post https://community.smartbear.com/t5/TestComplete-General-Discussions/Unable-to-handle-the-error-using-the-script-quot-Unable-to-find/m-p/170363/highlight/true#M31588 to get the understanding about how TestComplete addresses sought for objects.
