Using #value= also does not trigger JavaScript events. That could be also the reason. You could add timing statements around those invocations to get the idea about the slowness most easily like this: t = Time.now assert_enabled puts Time.now - t # how many seconds did it take time
Just add those statements in the source code and you'll get some idea, what is the slow part. If you'd like more complex and thorough solution, then you can use some profilers. Jarmo On Jul 29, 7:30 pm, JMI <[email protected]> wrote: > >I'd ask why in the hell you've created such a website in the first > >place? :P > > My AUT is not a website, it's a complex application that is deployed via an > HTML server and can be accessed by thin clients. It is not my creation, it > is my reality! The html pages I attached to this thread have been created > just to illustrate the problem. > > >Can't say for sure though why it's slower than with VB. This would > >need some debugging to do. > > By digging thought the Watir surce code, (input_elements.rb) I found that > the method set(value) of the class TextField invokes three other methods > before actually setting the value of the field: assert_exists, > assert_enabled and assert_not_readonly (very good!). There exists another > method in the same class that does almost the same: value=(v). It sets the > value of the field (as set(value) does), but does not call neither > assert_enabled nor assert_not_readonly. And it is fast! (To try this, > replace .set('123456789' by .value = '123456789' in my demo code). So now > the question is: why the methods assert_enabled and assert_not_readonly (one > of them or both) are slow for elements located within nested frames! (And > yes, in VB, equivalents of those methods are fast). > > To be continued... -- Before posting, please read http://watir.com/support. In short: search before you ask, be nice. [email protected] http://groups.google.com/group/watir-general [email protected]
