How to Map a JS Element
Hello, I'm having some trouble when trying to map some features from my WebSite. Actually, if I start capturing a moviments in my webSite the TestComplete doesn't recognize at all lots of screens. Wh...
Forum Discussion
Alex .... I think the problem with that approach is:
- "but the number of elements(rows) would be same, less, bigger"
So if it could return a table of the same size you are down to what is effectively a hard coded delay (whatever the timeout on your loop is) so no better than using a basic Delay(). It's an update, rather than a load from nothing. So it could update from 10 rows to the 10 rows again. Rowcount doesn't change. Loop simply times out ....
I'm wondering if you could possible also look at the page ReadyState? It depends how it's loading and whether that's reflected in the page ReadyState ....
(And also if Chrome - if that is the browser in use - have fixed the bug where it ALWAYS returns ready, regardless whether it actually is or not ...)
Hi Colin,
> page ReadyState
No, it does not work in most cases. The reason is that this property is set to True when the browser receives complete page that was requested previously. But after the page was received, a good number of scripts can be executed on the page. As these scripts do not reload the page, the value of PageReady remains the same (True), but scripts can request additional data from the server and inject obtained data (after possible additional complex processing) into the page changing its presentation significantly. And again, as all these scripts do not reload the page but just wait (if they are synchronous) for the data to be obtained and process them, this leaves PageReady with the same True value but the page in the browser is usually unresponsive. (Or is responsive in case of async requests but may change sporadically and unpredictably.)
> [...] it could update from 10 rows to the 10 rows again.
Well, I can imagine that there may be specifics when suggested approach will not work. (This is just a suggested approach, nothing more.) But even in the case of update, the events sequence is usually like this: empty table is created or existing table is cleared from data; new data are requested from the server; some delay until requested data arrive; arrived data processed and injected into the table. Usually, test code in the suggested approach is able to detect change in the number of records when the table is cleared. But even in the case when the update is lightning fast, the number of records in the table will be noted, loop entered, short delay performed, current number of table records evaluated and the loop will be exited because the number of records does not change. Note (if this was not clear enough from my previous description) that there are two conditions for the loop to exit: same number of records in the table or timeout. With this in mind, the possible risk is rather that the loop may exit too early if new records are added to the table slower than the inner loop's delay. Or if the page script code that populates table processes all obtained data and inserts all data to the table in one shot instead of adding them record by record. In these cases, if there is no additional indication that the table is empty (some text on the page or the value of some internal property), test code may decide that table is already populated with data and advance further while actually table will still be in the 'updating' state.
All the above means that the suggested approach is not a universal one, but depends on the implementation of the given web page.
