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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > >> 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 < > [email protected]> > >> > 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 <[email protected]> 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 <[email protected]> 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 > >> >>>> <[email protected]> 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 > >> >>>> > <[email protected]> > >> >>>> > wrote: > >> >>>> >> > >> >>>> >> Brilliant! > >> >>>> >> > >> >>>> >> On Feb 25, 2010 1:26 AM, "Jarmo" <[email protected]> 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 > >> >>>> >> <[email protected]> > >> >>>> >> wrote: > >> >>>> >> > I have tried it a... > >> >>>> >> > >> >>>> >> _______________________________________________ > >> >>>> >> Wtr-development mailing list > >> >>>> >> [email protected] > >> >>>> >> http://rubyforge.org/mailman/listinfo/wtr-development > >> >>>> > > >> >>>> > > >> >>>> > _______________________________________________ > >> >>>> > Wtr-development mailing list > >> >>>> > [email protected] > >> >>>> > http://rubyforge.org/mailman/listinfo/wtr-development > >> >>>> > > >> >>>> _______________________________________________ > >> >>>> Wtr-development mailing list > >> >>>> [email protected] > >> >>>> http://rubyforge.org/mailman/listinfo/wtr-development > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> Wtr-development mailing list > >> >>> [email protected] > >> >>> http://rubyforge.org/mailman/listinfo/wtr-development > >> >> > >> >> > >> >> _______________________________________________ > >> >> Wtr-development mailing list > >> >> [email protected] > >> >> 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 > >> > [email protected] > >> > http://rubyforge.org/mailman/listinfo/wtr-development > >> > > >> _______________________________________________ > >> Wtr-development mailing list > >> [email protected] > >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > > > _______________________________________________ > > Wtr-development mailing list > > [email protected] > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/wtr-development >
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
