Are you sure what event the javascript is looking for?  have you
looked at the object on the page and seen what event handlers are
defined for it?   maybe it's not the 'click' event that it wants?
maybe it wants some other sequence such as onfocus or onmouseup

On Apr 15, 2:54 am, Jarmo Pertman <jarm...@gmail.com> wrote:
> Well, for me the case is as following. User fills in some form and
> presses submit, which has onclick event attached to it, which in turn
> invokes JavaScript (not Java!) function, which validates form and if
> there are missing or invalid fields, submit will not be done and error
> message div will be created or updated with details what is wrong with
> fields. This seems to take more than my measured critical point, e.g.
> 220 ms. So it is not like 20 minutes. When you do .click, then Watir
> waits for page load (it might take 20 minutes), so why wouldn't it be
> reasonable to wait until events have been processed?
>
> Anyway, as I said, I can wait for error message div to be changed as
> my example code, which checks contents div html against old html, but
> it doesn't work. My questions were, why isn't onclick event fired (I
> can sleep even 10 seconds and it won't change error message div
> contents). If I click it manually, it takes below 1 second, always.
> So, sleep doesn't work either. It seems that for some reason win32ole
> IE object doesn't handle .click correctly in some strange situations.
> It doesn't even matter if I .fire_event("onclick") right after .click
> (or before). Also, as I've mentioned, then it will always work if I
> will execute commands one by one (with debugger or just while true;
> eval(gets); end;), so it seems that the problem is happening when I'm
> trying to do anything right after issuing .click. Even sleep hangs the
> process.
>
> How would you suggest that I'd use brute-force? Just click button so
> many times as error_message div changes finally?
>
> Jarmo
>
> On Apr 14, 9:55 pm, Chuck van der Linden <sqa...@gmail.com> wrote:
>
>
>
> > On Apr 14, 5:42 am, Jarmo Pertman <jarm...@gmail.com> wrote:
>
> > >Anyway, now I have completely different problem. Problem is related
> > >with fire_event. I have always assumed that Watir knows when
> > >fire_event call has finished, but it seems that IE will respond
> > >immediately to this call.
>
> > The firing of the event *has* finished amost as soon as it's started.
> > The issue is what processes are kicked off in the client side code
> > when the event is detected.
>
> >  I don't think Watir has (nor is it reasonable to expect it to have)
> > any way to tell what will happen when the event is fired, and how long
> > that will take to finish.  heck it could be a local flash animation or
> > something that takes 20 minutes to run.
>
> > brute force would just be to put in a wait (that would be long enough
> > to cover the time needed in any conceivable case), for the java to
> > finish doing it's thing.  Frankly unless execution speed is absolutely
> > critical, that would be my approach.
>
> > beyond that you'll have to examin what happens that is triggered by
> > the event, try to find the last thing it does, and make a loop or
> > something that looks for that to be the case (something is visible
> > perhaps?, or now exists that didn't exist before?   But you have to
> > ask yourself 'how long is it going to take me to do that, vs the time
> > I'd save during script execution over just using the brute force
> > method.  There may not be much return on the time invested to create
> > the more elegant solution.- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Watir General" group.
To post to this group, send email to watir-general@googlegroups.com
Before posting, please read the following guidelines: 
http://wiki.openqa.org/display/WTR/Support
To unsubscribe from this group, send email to 
watir-general-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/watir-general
-~----------~----~----~----~------~----~------~--~---

Reply via email to