On Jul 28, 2006, at 7:30 PM, Bret Pettichord wrote:
On 7/28/06, Xavier Noria <[EMAIL PROTECTED]> wrote: I'm gonna patch the method tomorrow to write some stack-based recursion. But before I do that I'd like to ask whether someone else already fixed this, or else if there is any technical reason that prevents that method from being recursive-like.Your solution sounds reasonable. Please submit a patch when you have it.
Great, here it is.I factored wait() out into wait_for_ie() and wait_for_document(). The patch is against 1.4.1, which is the one we are using.
In addition to the stack-based recursion through frames I planned to add, I removed an unusued @pageHasReloaded flag, and added a do/while loop in wait_for_ie() because another reason why the program was crashing was that after the usual while busy + until readyState == complete the @ie object was again in a busy state! Argh! I have seen the do/while in wait_for_ie() sometimes executes more than once in that website with frames, for sure.
That do/while loop is not a correct solution to the re-busy state. In principle it could happen that whatever puts @ie back in busy state may need a bit more to be triggered than those 0.02 seconds of sleep. But at least my program runs like a charm in my trials, and approach that problem properly I'd need to know more about those IE states than what I've found in the docs. In particular it's relationship with frames, DOM scripting, Ajax calls... Smells like an asynchronous thing to hook into if there's API for that. I am sure there's room for improvement there.
-- fxn
adds_robustness_to_watir.patch
Description: Binary data
_______________________________________________ Wtr-general mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-general
