I got the same error, but the problem is not with click_no_wait.
The problem is that Watir's default timeout of 2 seconds isn't long enough
to wait for that modal dialog to open. Adding this line to your script fixes
it:
Watir::IE.attach_timeout = 15
This is probably a good argument for changing the default timeout in Watir
to something a bit longer.
Bret
On Wed, Feb 24, 2010 at 6:36 PM, Alister Scott <alister.sc...@gmail.com>wrote:
> I have tried click_no_wait on ruby 1.8.6-27 rc2 and it doesn't work.
> Using work machine: Win XP, IE6
>
> Script:
>
> require 'watir'
> b = Watir::Browser.new()
> b.goto("
> http://samples.msdn.microsoft.com/workshop/samples/author/dhtml/refs/showModalDialog2.htm
> ")
> b.button(:value,"Push To Create").click_no_wait
> puts b.modal_dialog(:title, "showModalDialog Method Sample Target
> Page").exists?
> puts b.modal_dialog(:title, "showModalDialog Method Sample Target
> Page").title
> b.modal_dialog(:title, "showModalDialog Method Sample Target Page").close
>
>
> Output
>
> >ruby clickwait.rb
> C:/Ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/modal_dialog.rb:51:in
> `locate': Modal Dialog with title showModalDialog Method Sample Target Page
> not found. Timeout = 2.0 (Watir::Exception::NoMatchingWindowFoundException)
> from
> C:/Ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/modal_dialog.rb:86:in
> `initialize'
> from
> C:/Ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/container.rb:186:in
> `new'
> from
> C:/Ruby/lib/ruby/gems/1.8/gems/watir-1.6.5/lib/watir/container.rb:186:in
> `modal_dialog'
> from clickwait.rb:5
> >Exit code: 1
>
> Bret, does this code work for you?
>
>
> 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 8:53 AM, Alister Scott <alister.sc...@gmail.com>wrote:
>
>> I will retest bug 320 tonight on 186-27rc2.
>> Last time I tried it wouldn't work with modal dialogs.
>>
>> 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 8:41 AM, Bret Pettichord <b...@pettichord.com>wrote:
>>
>>> Thanks for the pointer to bug 320. It seems like we need more info.
>>> Everyone here at Convio is happy with the fix in 1.6.5. -- we've been using
>>> 186-27rc2 for some time. But Alister said he didn't see it working for him.
>>>
>>> Bret
>>>
>>> On Wed, Feb 24, 2010 at 11:55 AM, Ethan <notet...@gmail.com> wrote:
>>>
>>>> Interestingly, that bug still seems to be present in the current 1.8.*
>>>> mingw32 builds, too. But not 1.9.1.
>>>> (first two are mswin32, rest are mingw32)
>>>>
>>>> C:\>c:\Ruby186-26\bin\ruby -e "puts \"Does this work?\""
>>>> Does this work?
>>>>
>>>> C:\>c:\Ruby186-27\bin\ruby -e "puts \"Does this work?\""
>>>> -e:1: unterminated string meets end of file
>>>>
>>>> C:\>c:\Ruby186-383\bin\ruby -e "puts \"Does this work?\""
>>>> -e:1: unterminated string meets end of file
>>>>
>>>> C:\>c:\Ruby186-398\bin\ruby -e "puts \"Does this work?\""
>>>> -e:1: unterminated string meets end of file
>>>>
>>>> C:\>c:\Ruby191-378\bin\ruby -e "puts \"Does this work?\""
>>>> Does this work?
>>>>
>>>> Anyway, if watir 1.6.5 does correctly work around it, may not matter in
>>>> any case.
>>>>
>>>> -Ethan
>>>>
>>>>
>>>> On Wed, Feb 24, 2010 at 12:37, Ethan <notet...@gmail.com> wrote:
>>>>
>>>>> I thought 1.8.6-27 (patchlevel 287) was the one with the bug that
>>>>> affected click_no_wait.
>>>>> That is what seems to be indicated by
>>>>> http://jira.openqa.org/browse/WTR-320 - but there are varying reports
>>>>> in the comments there of whether or not it's still an issue with watir
>>>>> 1.6.5.
>>>>>
>>>>> I've been on 1.8.6-26 (patchlevel 111) until recently trying out the
>>>>> shiny new mingw32 builds, which are nice except for that annoying DL bug
>>>>> (I've switched from DL to FFI on my fork, so avoided that issue).
>>>>>
>>>>> -Ethan
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 24, 2010 at 12:13, Bret Pettichord <b...@pettichord.com>wrote:
>>>>>
>>>>>> I should have said that I was thinking of recommending
>>>>>>
>>>>>> 1.8.6-27RC2
>>>>>> http://rubyforge.org/frs/shownotes.php?release_id=28426
>>>>>>
>>>>>> This is what I've been using for some time.
>>>>>>
>>>>>> I agree that it is too soon to recommend the new mingw32 installers.
>>>>>>
>>>>>> Bret
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 24, 2010 at 10:32 AM, Ethan <notet...@gmail.com> wrote:
>>>>>>
>>>>>>> The new 1.8.* RCs using the mingw32 compiler have an issue with DL
>>>>>>> callbacks causing segfaults. WinClicker uses DL callbacks.
>>>>>>> To demonstrate:
>>>>>>>
>>>>>>> > c:\Ruby187-249\bin\irb -r winClicker
>>>>>>> >> w=WinClicker.new
>>>>>>> => #<WinClicker:0x2db6070 @User32=#<DL::Handle:0x2db6028>>
>>>>>>> >> w.getWindowHandle('')
>>>>>>> ./winClicker.rb:244: [BUG] Segmentation fault
>>>>>>> ruby 1.8.7 (2010-01-10 patchlevel 249) [i386-mingw32]
>>>>>>>
>>>>>>> This application has requested the Runtime to terminate it in an
>>>>>>> unusual way.
>>>>>>> Please contact the application's support team for more information.
>>>>>>>
>>>>>>> I think it best to hold off on recommending this for now. I'm opening
>>>>>>> a bug report for this today - meant to earlier, but it slipped my mind.
>>>>>>>
>>>>>>> -Ethan
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Feb 24, 2010 at 10:31, Bret Pettichord
>>>>>>> <b...@pettichord.com>wrote:
>>>>>>>
>>>>>>>> Just thought of something.
>>>>>>>>
>>>>>>>> I'm wondering if we should now recommend using 1.8.7-rc whatever.
>>>>>>>> There was one bug with click_no_wait that only showed up in 1.8.7, but
>>>>>>>> that
>>>>>>>> is fixed now. And I think rubygems works better with 1.8.7 -- we have
>>>>>>>> a lot
>>>>>>>> of comments about how to upgrade rubygems that I think become
>>>>>>>> non-issues if
>>>>>>>> we recommend 1.8.7.
>>>>>>>>
>>>>>>>> Bret
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>
--
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
