I agree, that is a bit strange... As noted above, I was able to do a click on a link off screen without having to call a "ScrollIntoView" call at all... TC took care of that..., so I know that TC DOES include that capability... what we are dealing with is trying to figure out WHY it's not working for you.
Question has come to mind... looking at the screenshots you posted... when you "scroll", are you scrolling the whole page or are you scrolling just a window WITHIN the page? I'm just kinda looking for differences between "normal" web pages and the dynamically rendered page you're working with.
The reason why I'm asking that has to do with the box that I have oulined in red... it appears that that particular area of the screen stays "static" while the rest of the page scrolls... and I wonder if that has anything to do with TC getting "confused".
No, that is not the case.
1. As you noticed, I use Sys.HighlightObject(), so I visually verify that it is the correct object.
2. I mentioned before that I manually intervened during script execution (I scrolled the page manually). I noticed that the script identified the object, highlighted it and interacted with it -- but ONLY after I scrolled the page. Meaning, TC does not get confused. It simply does not know how to handle this.
I agree with you that usually, TC does handle objects and does scroll, however Robert, we don't get paid for usually doing our job...... These types of issues should be very well handled by smartbear.
Furthermore, this page provides more challenges that smartbear cannot handle; for example
- TC will not click on radio buttons consistently
- TC cannot recognize a dropdown list boxes consistently ( I think I shared this issue with you.)
- TC WILL NOT select a subitem (in a dropdown) that is not visible (going back to using scrollIntoView within a listbox....
This is frustrating and disappointing to say the least.
Hi,
Just several notes that might or might not appear to be relevant...
> Shouldn't this be at the core of what an automation tool is? [From the initial post]
I think this depends on what level of control test tool provides you with. Assuming that the tool implements automatic scrolling into the view before clicking, this definitely may ease your efforts with test code, but, on the other hand, this might make it not possible, for example, to check if some UI element can be accessed by the end user...
I don't remember if I explicitly checked this myself, but I tend to agree with Robert that TestComplete scrolls UI elements into view before clicking them. But only for the simple enough page designs.When a page is overloaded with the modern fancy staff like dynamically positioned panels, with a scrollers inside them, when some of them scrolls with the page while others are not pretending to look like sticked to some edge of the page, etc. -- even for human sometimes it is not easy to scroll the required element into the view and for such pages TestComplete's automatic scroll does not work.
You are providing screenshots with the browser's Inspector views. This is good for illustration, but I would recommend to use TestComplete's Object Browser to inspect objects' properties. Just because TestComplete uses the object model provided by Object Browser and it may differ from what is shown in the browser Inspector.
For example, I would recommend to stop on the breakpoint just before the line of code that tries to interact with the problematic Guaranteed Hours input field and check in the Object Browser the properties of this and parent objects - are they really enabled and within the view? Can the field be interacted with if after inspection you try to Step Over in the debugger? (I.e. does this look like timing issue?) You may talk with developers or examine page source code to check if this field (or one of its parents) is initially disabled and is enabled by some script function that is triggered at some other place and needs some time to execute.
You are using .SetText() in your code. What if you change it to .Keys() ?
You are saying that code behaves inconsistently - what does it mean? Does it mean that sometimes test succeeds while sometimes fails because of the error from the subject? If my guess is correct, than it looks like timing issue when some controls are dynamically modified and your code must wait until this modification is done.
This is personal, but I prefer to use Aliases and FindXX() functions from TestComplete but not XPath. To me, XPath in a very rare cases is descriptive enough to understand later what control was searched. From your code: you are looking for some unnamed input control that is a child of a bunch of unnamed panels below some form. Will it be an easy task to figure out what control was sought for if developers do even a single change in a page design?
In any case, regardless of whether control is found via Xpath or not, it might be useful to wait until it is in the 'ready' state by using WaitProperty() function.
Instead of clicking on the control and setting the value, what if you try just to set focus to the control and try to type:
inputGuaranteedHours.Focus();
inputGuaranteedHours.Keys("^A" + "Some typed value");
I've had embedded windows where ScrollIntoView and suchlike did not work properly.
I agree with the others. In most cases, TestComplete will handle this for you. But there are so many variations and different ways of doing things now, and it's a fast moving field, that expecting automation software to keep up with every single possibility and to do everything for you out of the box is simply not realistic. (I'd love it if TestComplete handled Awesomium wrappers for example .... but it doesn't. And I'm realistic enough to know that me asking for it will not get it added to TestComplete overnight.)
You mention you can scroll the page/frame (whatever - the part that contains the control you need) manually? So I presume you can replicate the manual scrolling via TestComplete? (I can see a scrollbar so I know there WILL be a way to do it. Might be obvious, might not.)
In that case, it sounds like you'll have to do the same as I did - write your own helper function.
Pretty simple - pass it the page/frame/container as an object, along with some references you know will allow it find the control you want. Then just scroll in stages (within a loop) and check for the desired control each time you do. Exit conditions for the loop being either finding the control or the scroller reaching it's endpoint.
The page will have dimensions. The scrollbar will have methods and properties to tell you where it's at. Etc etc.
Not ideal I agree. I would much rather it did it for me. But if it doesn't? What else can you do?
My experience says there is almost always a way. Just that some of the solutions require a little more "out of the box" thinking than others. Answers aren't always handed to you on a plate ....
Sounds like you're dealing with some pretty unique situations. Have you attempted to create a direct support case with the SmartBear folks? If you are working with some technological challenges that they hadn't anticipated, it's my experience that they are usually pretty good at resolving such things quickly.
Unfortunately, without access to the website that you are testing against, the best I can do is what I've been doing... giving conjecture as to what potentially may be the problem. I think there is a solution, but it might not be 100% straightforward because, honestly, you're not testing a 100% straightforward web page. :)
I did create a case with smartbear, unfortunately no response from there.... that is the reason I reach out to the community.
I am sure they monitor this site, yet no one from support seemed to join this thread....
What does that say..
It says that urgent support is done through test cases... stuff that is more leisurely is handled through the community. :)
My suggestion is, again, to open another support case indicating that the previously suggested corrected did not solve the problem. In my experience, turn around time for a response is within 24 hours. They do keep working on a solution until a problem is resolved.
However, perhaps DanaRogo or someone else can ping support to take a closer look here. This does appear to be a rather unique situation.
I know I can count on you Robert :smileyvery-happy:
And the community
