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
> 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
