Sounds like a good idea to me. Cheers,
Alister On Mon, Mar 1, 2010 at 8:55 AM, Charley Baker <charley.ba...@gmail.com>wrote: > Nothing personal, but this thread has gotten overloaded. We need split off, > the initial topic being should we recommend 1.8.7 or 186 something or some > variant there of. I'm still not clear on that point. I'll start a new thread > on that. Then there's click_no_wait based on Jarmo's stuff, sounds like a > possible fork include on github, open a new thread for that if you want to > discuss it further. :) And then there's global $DEBUG which affects that, > but honestly not related. > > My suggestion is split off into separate threads on this list. I'll take > the Ruby version update and try to summarize what we have, and then another > summary of Jarmo's debugging on click_no_wait if you want to continue that > on. I don't belabor the point, and I think we can take care of the > conditional case w/o a lot of debug overhead. > > Yeah/nay? > > -Charley > > > > Charley Baker > blog: http://blog.charleybaker.org/ > Lead Developer, Watir, http://watir.com > QA Architect, Gap Inc Direct > > > On Sun, Feb 28, 2010 at 3:23 AM, Jarmo <jarm...@gmail.com> wrote: > >> You are probably correct, but i don't think that you can suppress >> those. Another way would be to use Logger class and then just modify >> log level to debug. It would be great if Logger would be used in many >> places so you could get some text on your screen when some element is >> located and clicked and so on - depending on the log level of course. >> >> Jarmo >> >> On Fri, Feb 26, 2010 at 10:31 PM, Bill Agee <billa...@gmail.com> wrote: >> > Regarding the built-in Ruby $DEBUG variable, I tried using it in a Watir >> > project at one point, but ended up not using it - because Watir's >> > dependencies generate lots of innocuous messages when it is enabled. >> > >> > I think Win32::API and Win32::OLE are the main culprits. If $DEBUG is >> true, >> > a lot of noise is printed to stdout whenever Watir is used to click >> elements >> > (at least in IE). >> > >> > There may be some way to suppress those messages, though...haven't >> checked. >> > >> > Thanks >> > Bill >> > >> > On Fri, Feb 26, 2010 at 3:31 AM, Jarmo <jarm...@gmail.com> wrote: >> >> >> >> Yup, I also thought that it would be great if it would be selectable >> >> by the user so they could at least give some information to anyone >> >> else who might understand the problem more. >> >> >> >> Anyway, the critical line is this in page-container.rb (i don't know >> >> about firewatir): >> >> exec_string = "start rubyw -e #{(load_path_code + '; ' + >> >> ruby_code).inspect}" >> >> >> >> As i understand, then there isn't much (or any) places in Watir's code >> >> where ruby variable $DEBUG is used? Anyway, that would be a one place >> >> to use it somehow like this: >> >> >> >> exec_string = $DEBUG ? "ruby" : "start rubyw" >> >> exec_string += " -e #{(load_path_code + '; ' + ruby_code).inspect}" >> >> >> >> So it would be easy to tell the users that just enable debug mode by >> >> using ruby -d or by setting $DEBUG to true. >> >> >> >> Jarmo >> >> >> >> On Fri, Feb 26, 2010 at 1:44 AM, Bret Pettichord <b...@pettichord.com> >> >> wrote: >> >> > I don't know. I'm confused and I think I need to retest some things. >> >> > >> >> > I also think we need to build some of Jarmo's debugging mods into the >> >> > next >> >> > version of Watir. >> >> > >> >> > Bret >> >> > >> >> > On Thu, Feb 25, 2010 at 4:38 PM, Alister Scott < >> alister.sc...@gmail.com> >> >> > wrote: >> >> >> >> >> >> So does this mean bug WTR-320 is considered fixed or still an issue? >> >> >> >> >> >> Does this mean we should still be recommending 1.8.6.26? >> >> >> >> >> >> Cheers, >> >> >> >> >> >> Alister Scott >> >> >> Brisbane, Australia >> >> >> Watir Web Master: http://watir.com >> >> >> Blog: http://watirmelon.com >> >> >> Google: http://www.google.com/profiles/alister.scott >> >> >> LinkedIn: http://www.linkedin.com/in/alisterscott >> >> >> >> >> >> >> >> >> On Fri, Feb 26, 2010 at 2:00 AM, Ethan <notet...@gmail.com> wrote: >> >> >>> >> >> >>> It does appear to be the same issue. >> >> >>> Incidentally, I didn't come up with that example; work figuring it >> out >> >> >>> was done by Jim Matthews; see >> >> >>> >> >> >>> >> http://groups.google.com/group/watir-general/msg/02a19203ed99e262?pli=1 >> >> >>> In my fork I rewrote click_no_wait to use a javascript setTimeout >> >> >>> rather >> >> >>> than a new process. It might be worth looking at doing the same >> with >> >> >>> watir. >> >> >>> >> >> >>> mine looks like: >> >> >>> document_object.parentWindow.setTimeout(" >> >> >>> (function(tagName, uniqueNumber) >> >> >>> { var candidate_elements=document.getElementsByTagName(tagName); >> >> >>> for(var i=0;i<candidate_elements.length;++i) >> >> >>> { if(candidate_elements[i].uniqueNumber==uniqueNumber) >> >> >>> { candidate_elements[i].click(); >> >> >>> } >> >> >>> } >> >> >>> })(#{self.tagName.inspect}, >> #{element_object.uniqueNumber.inspect}) >> >> >>> ", 0) >> >> >>> >> >> >>> (actually, it doesn't look like that anymore since I modified it to >> >> >>> fire >> >> >>> onmousedown; fire onmouseup; then click, but that's what it looked >> >> >>> like not >> >> >>> too long ago when it behaved as watir's #click does now) >> >> >>> >> >> >>> -Ethan >> >> >>> >> >> >>> On Thu, Feb 25, 2010 at 05:38, Jarmo <jarm...@gmail.com> wrote: >> >> >>>> >> >> >>>> This seems to be something similar to the Ethan's examples... Or? >> >> >>>> >> >> >>>> Jarmo >> >> >>>> >> >> >>>> On Thu, Feb 25, 2010 at 12:02 PM, Alister Scott >> >> >>>> <alister.sc...@gmail.com> wrote: >> >> >>>> > Nice one Jarmo! >> >> >>>> > >> >> >>>> > I get the following error: -e:1: syntax error, unexpected >> >> >>>> > tSTRING_BEG, >> >> >>>> > expecting $end >> >> >>>> > >> >> >>>> > This is the code that was generated: >> >> >>>> > >> >> >>>> > ruby -e "temp = >> >> >>>> > >> >> >>>> > >> >> >>>> > >> Array.new([\"C:/Ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/win32ole\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/json_pure-1.2.0/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/json_pure-1.2.0/lib\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/gemcutter-0.4.1/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/gemcutter-0.4.1/lib\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/xml-simple-1.0.12/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/xml-simple-1.0.12/lib\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/rubyforge-2.0.3/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/rubyforge-2.0.3/lib\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/rake-0.8.7/lib\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/hoe-2.5.0/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/hoe-2.5.0/lib\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/s4t-utils-1.0.4/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/s4t-utils-1.0.4/lib\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/builder-2.1.2/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/builder-2.1.2/lib\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/user-choices-1.1.6.1/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/user-choices-1.1.6.1/lib\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.5/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/commonwatir-1.6.5/lib\", >> >> >>>> > >> >> >>>> > >> \"C:/Ruby/lib/ruby/gems/1.8/gems/win32-api-1.4.6-x86-mswin32-60/bin\", >> >> >>>> > >> >> >>>> > >> \"C:/Ruby/lib/ruby/gems/1.8/gems/win32-api-1.4.6-x86-mswin32-60/lib\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/windows-api-0.4.0/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/windows-api-0.4.0/lib\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/windows-pr-1.0.9/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/windows-pr-1.0.9/lib\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/win32-process-0.5.9/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/win32-process-0.5.9/lib\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/activesupport-2.3.5/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/activesupport-2.3.5/lib\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.5/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/firewatir-1.6.5/lib\", >> >> >>>> > >> \"C:/Ruby/lib/ruby/gems/1.8/gems/nokogiri-1.4.1-x86-mswin32/bin\", >> >> >>>> > >> \"C:/Ruby/lib/ruby/gems/1.8/gems/nokogiri-1.4.1-x86-mswin32/lib\", >> >> >>>> > >> \"C:/Ruby/lib/ruby/gems/1.8/gems/nokogiri-1.4.1-x86-mswin32/ext\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/bin\", >> >> >>>> > \"C:/Ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib\", >> >> >>>> > \"C:/Ruby/lib/ruby/site_ruby/1.8\", >> >> >>>> > \"C:/Ruby/lib/ruby/site_ruby/1.8/i386-msvcrt\", >> >> >>>> > \"C:/Ruby/lib/ruby/site_ruby\", \"C:/Ruby/lib/ruby/1.8\", >> >> >>>> > \"C:/Ruby/lib/ruby/1.8/i386-mswin32\", \".\"]); >> $LOAD_PATH.clear; >> >> >>>> > temp.each >> >> >>>> > {|element| $LOAD_PATH << element}; require 'watir/ie'; pc = >> >> >>>> > Watir::IE.attach(:hwnd, 328788); >> >> >>>> > pc.instance_eval(\"Watir::Button.new(self, >> >> >>>> > :unique_number, 1).click!\")" >> >> >>>> > >> >> >>>> > Cheers, >> >> >>>> > >> >> >>>> > Alister Scott >> >> >>>> > Brisbane, Australia >> >> >>>> > Watir Web Master: http://watir.com >> >> >>>> > Blog: http://watirmelon.com >> >> >>>> > Google: http://www.google.com/profiles/alister.scott >> >> >>>> > LinkedIn: http://www.linkedin.com/in/alisterscott >> >> >>>> > >> >> >>>> > >> >> >>>> > On Thu, Feb 25, 2010 at 6:05 PM, Bret Pettichord >> >> >>>> > <b...@pettichord.com> >> >> >>>> > wrote: >> >> >>>> >> >> >> >>>> >> Brilliant! >> >> >>>> >> >> >> >>>> >> On Feb 25, 2010 1:26 AM, "Jarmo" <jarm...@gmail.com> wrote: >> >> >>>> >> >> >> >>>> >> Hello. >> >> >>>> >> >> >> >>>> >> I've written about debugging click_no_wait. This is for 1.6.2, >> but >> >> >>>> >> i'm >> >> >>>> >> sure it's quite similar for 1.6.5 also. Anyway, give it a try >> and >> >> >>>> >> see >> >> >>>> >> what you get. >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> http://itreallymatters.tumblr.com/post/378669758/debugging-watirs-click-no-wait-method-problems >> >> >>>> >> >> >> >>>> >> Jarmo >> >> >>>> >> >> >> >>>> >> On Thu, Feb 25, 2010 at 8:05 AM, Alister Scott >> >> >>>> >> <alister.sc...@gmail.com> >> >> >>>> >> wrote: >> >> >>>> >> > I have tried it a... >> >> >>>> >> >> >> >>>> >> _______________________________________________ >> >> >>>> >> Wtr-development mailing list >> >> >>>> >> Wtr-development@rubyforge.org >> >> >>>> >> http://rubyforge.org/mailman/listinfo/wtr-development >> >> >>>> > >> >> >>>> > >> >> >>>> > _______________________________________________ >> >> >>>> > Wtr-development mailing list >> >> >>>> > Wtr-development@rubyforge.org >> >> >>>> > http://rubyforge.org/mailman/listinfo/wtr-development >> >> >>>> > >> >> >>>> _______________________________________________ >> >> >>>> Wtr-development mailing list >> >> >>>> Wtr-development@rubyforge.org >> >> >>>> http://rubyforge.org/mailman/listinfo/wtr-development >> >> >>> >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Wtr-development mailing list >> >> >>> Wtr-development@rubyforge.org >> >> >>> http://rubyforge.org/mailman/listinfo/wtr-development >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> Wtr-development mailing list >> >> >> Wtr-development@rubyforge.org >> >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> >> > >> >> > >> >> > >> >> > -- >> >> > Bret Pettichord >> >> > Lead Developer, Watir, www.watir.com >> >> > >> >> > Blog, www.io.com/~wazmo/blog <http://www.io.com/%7Ewazmo/blog> >> >> > Twitter, www.twitter.com/bpettichord >> >> > >> >> > >> >> > _______________________________________________ >> >> > Wtr-development mailing list >> >> > Wtr-development@rubyforge.org >> >> > http://rubyforge.org/mailman/listinfo/wtr-development >> >> > >> >> _______________________________________________ >> >> Wtr-development mailing list >> >> Wtr-development@rubyforge.org >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> > >> > >> > _______________________________________________ >> > Wtr-development mailing list >> > Wtr-development@rubyforge.org >> > http://rubyforge.org/mailman/listinfo/wtr-development >> > >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development@rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development@rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development >
_______________________________________________ Wtr-development mailing list Wtr-development@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-development
