I'm responding to an old thread -- catching up on my email. In this proposal (from March), Ethan provided a Jira ticket and code patches. http://jira.openqa.org/browse/WTR-146
My understanding is that this proposal can be summarized in two points. 1. Provide the same options to Filefield#set as currently exist for Element#click. 2. Change the API. If this is correct, then i would like to consider the two parts of proposal separately. If not, i would like to know what else is being proposed. Bret Ethan Jewett wrote: > I think that the addition of the "click" to file_field.set in this > change (see thread below) is causing one of my tests to hang during > the @container.wait in the "click" method. However, this problem > didn't show up until after the changes to the wait functionality in > mid-February. Or so my theory goes . . . > > The fix, in my case, is to change the "click" to a "click!" in > file_field.set, by-passing the @container.wait in the click method. I > suppose I could use a time-out technique instead. > > I can't provide a test case, unfortunately, because I don't have a > handle on all the javascript eventing and fancy ajax-y reload in > various frames that's going on in a generated SAP business server > pages app. I think this is a relatively well-known issue with > ajax-like apps. Please correct me if I'm wrong. > > Attached is a patch to the 1.5.1163 revision that illustrates the way > I've modified watir.rb to allow me to specify wait behavior in the > file_field.set method. The "watir 1.5.1163 - no_wait option in > file_field.set.patch" basically throws any extra arguments on > file_field.set into an args_hash Hash. The "set" method then checks > for the :no_wait key and either "click"s or "click!"s based on that > key. > > So, > > file_field.set(path) results in a "click" > file_field.set(path, :no_wait => false) results in a "click" > file_field.set(path, :no_wait => true) results in a "click!" > > The upside here is that this doesn't change existing behavior. The > downside is that it is kind of a hack as it stands. > > I think that implementing this sort of functionality in a more general > (and perhaps better thought-out) way would give a lot of flexibility > to those of us dealing with ajax goodness to manually override wait > functionality when necessary. It might also be a reasonably standard > way to allow granular control of other functionality on a method-call > by method-call basis. > > Is this reasonable? Has something like this been decided against in > the past? Is it too big a change for 1.5? Thoughts on problems? > Improvements? Maybe using :wait => false instead of :no_wait => true > would be more intuitive? > > I don't think this patch is ready to go into the code-base as it > stands, even if people think it is a reasonable approach, but I'll > submit a Jira ticket once I have something that I think will work. > > Thanks, > Ethan > > On 1/10/07, Bret Pettichord <[EMAIL PROTECTED]> wrote: >> John Lolis wrote: >> > I registered AutoItX3.dll using regsvr32 and it got rid of the >> error message, the problem now is it doesn't fill in the field with >> any text. I can flash it, so i know I have the right field - I just >> can't put anything in there. >> > >> > any more ideas? >> > >> >> Today I checked in fixes for both this and the other problem (autoit >> registration). These are NOT in today's dev gem, but will be in the next >> one. You can pull them from trunk if you like. >> >> A workaround for this problem for earlier versions of 1.5 is this: >> >> 1. Manually register autoit: >> >> >regsvr32 AutoItX3.dll >> >> 2. Add a call to click: >> >> ie.file_field(:id, >> 'DriverFileUpload_DriverFileUpload').set(filename) >> ie.file_field(:id, 'DriverFileUpload_DriverFileUpload').click >> >> Please let us know if either of these solutions does not fix this >> problem for anyone. >> >> Bret >> _______________________________________________ >> Wtr-general mailing list >> Wtr-general@rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-general >> > ------------------------------------------------------------------------ > > _______________________________________________ > Wtr-general mailing list > Wtr-general@rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-general _______________________________________________ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
