|
List Info
Thread: very neat trick with Ruby system() (or any other language on Windows)
|
|
| very neat trick with Ruby system() (or
any other language on Windows) |
|
2006-06-14 22:14:42 |
Hi...
As we all know,
system("foo.exe")
does not return control to the calling script until
"foo.exe" has finished.
however, system("start foo.exe")
does. This has interesting implications for performance
testing and
for running many test files simultaneously from a controller
script.
A colleague just showed this to me today. If I had known
this three
or four years ago, I would be a much happier (although more
ignorant)
scripter.
-Chris
_______________________________________________
Wtr-general mailing list
Wtr-general rubyforge.org
htt
p://rubyforge.org/mailman/listinfo/wtr-general
|
|
| very neat trick with Ruby system() (or
any other language on Windows) |
|
2006-06-14 23:47:29 |
|
On 6/14/06, Chris McMahon <gmail.com">christopher.mcmahongmail.com> wrote:
As we all know,
system("foo.exe";)
does not return control to the calling script until "foo.exe" has finished.
however, system("start foo.exe")
does. ;This has interesting implications for performance testing and
for running many test files simultaneously from a controller script.
I just updated the code used by click_no_wait to use this technique to avoid having to spawn a thread. Thanks.
|
| very neat trick with Ruby system() (or
any otherlanguage on Windows) |
|
2006-06-15 17:07:04 |
|
I updated my Watir this morning to the most current and when
I ran my script that used the click_no_wait I get this error:
NameError: undefined local variable or method
`attach_command' for #<Watir::Frame:0x2cc1780>
C:/ruby/lib/ruby/site_ruby/1.8/watir.rb:1189:in `eval_in_spawned_process'
C:/ruby/lib/ruby/site_ruby/1.8/watir.rb:2411:in `click_no_wait'
On further investigation there are 2 methods in Watir with
that name:
watir.rb (2170): def
attach_command
watir.rb (2647): def
attach_command
Do I need to do something else (require, include, etc) or do
I need to update some other file or what?
Thanks,
From: wtr-general-bouncesrubyforge.org
[mailto:wtr-general-bouncesrubyforge.org] On
Behalf Of Bret Pettichord
Sent: Wednesday, June 14, 2006
4:47 PM
To: wtr-generalrubyforge.org
Subject: Re: [Wtr-general] very
neat trick with Ruby system() (or any otherlanguage on Windows)
On 6/14/06, Chris
McMahon <gmail.com">christopher.mcmahongmail.com>
wrote:
As we
all know,
system(";foo.exe")
does not return control to the calling script until "foo.exe" has
finished.
however, system("start foo.exe")
does. This has interesting implications for performance testing and
for running many test files simultaneously from a controller script.
I just updated the code used by click_no_wait to use this technique to avoid
having to spawn a thread. Thanks.
|
| very neat trick with Ruby system() (or
any otherlanguage on Windows) |
|
2006-06-15 17:20:52 |
|
This is a "known" problem. (In other words, i knew about it, but it wasn't well documented.)
http://jira.openqa.org/browse/WTR-6
The fix is for a Watir developer to write attach_command for Frames. David, this bug is currently assigned to you, but the surrounding code has changed since you signed up for this. Do you still want to do it?
BTW, click_no_wait was recently enhanced so that it works in any context as long as you are not using frames. (If you see otherwise, please report it).
Bret
On 6/15/06,
Cain, Mark <rl.gov">Mark_Cainrl.gov>; wrote:
I updated my Watir this morning to the most current and when
I ran my script that used the click_no_wait I get this error:
NameError: undefined local variable or method
`attach_command' for #<Watir::Frame:0x2cc1780>
C:/ruby/lib/ruby/site_ruby/1.8/watir.rb:1189
:in `eval_in_spawned_process'
C:/ruby/lib/ruby/site_ruby/1.8/watir.rb:2411
:in `click_no_wait'
On further investigation there are 2 methods in Watir with
that name:
watir.rb (2170): def
attach_command
watir.rb (2647): def
attach_command
Do I need to do something else (require, include, etc) or do
I need to update some other file or what?
Thanks,
On 6/14/06, Chris
McMahon <gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">christopher.mcmahongmail.com>
wrote:
As we
all know,
system(";foo.exe")
does not return control to the calling script until "foo.exe" has
finished.
however, system("start foo.exe")
does. This has interesting implications for performance testing and
for running many test files simultaneously from a controller script.
I just updated the code used by click_no_wait to use this technique to avoid
having to spawn a thread. Thanks.
_______________________________________________
Wtr-general mailing list
rubyforge.org">Wtr-generalrubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general
|
| very neat trick with Ruby system() (or
any otherlanguage on Windows) |
|
2006-06-15 22:23:05 |
Bret,
The current method is quite a bit different than the method
that I
wrote, and I'm not sure it will be as flexible. (For
example, you can't
attach to a Frame the way you can to an IE or Modal window.)
My method
is designed to completely re-create the exact method string
to get back
to the element to be clicked, and is working well for me
right now,
though there are some inconsistencies with table related
elements (which
is what got me looking at our current container/collection
issue).
I will probably give it another try once trunk settles down
a bit and
after we get the container/collection settled, but right now
I'm getting
ready to work on the container/collection issue first.
Mark, you may want to look at the modal_dialog branch, which
is what I'm
using where I work, but right now it's missing a lot of the
recent
changes to trunk.
It's at https://svn.openqa.org/svn/watir/branches/modal_dial
og/watir and
I'm doing lots of click_no_wait's from within frames.
Feel free to
contact me if you have questions about the code in that
branch as it's
pretty much my branch right now and it's probably a dead
end until it's
decided to port that code to the current trunk.
David
Bret Pettichord wrote:
> This is a "known" problem. (In other words,
i knew about it, but it
> wasn't well documented.)
>
> http://jira.openq
a.org/browse/WTR-6
>
> The fix is for a Watir developer to write
attach_command for Frames.
> David, this bug is currently assigned to you, but the
surrounding code
> has changed since you signed up for this. Do you still
want to do it?
>
> BTW, click_no_wait was recently enhanced so that it
works in any
> context as long as you are not using frames. (If you
see otherwise,
> please report it).
>
> Bret
_______________________________________________
Wtr-general mailing list
Wtr-generalrubyforge.org
htt
p://rubyforge.org/mailman/listinfo/wtr-general
|
|
| very neat trick with Ruby system() (or
any otherlanguage on Windows) |
|
2006-06-16 18:53:02 |
|
On 6/15/06, David Schmidt <tower-mt.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">davidstower-mt.com> wrote:
Bret,
The current method is quite a bit different than the method that I
wrote, and I'm not sure it will be as flexible. (For example, you can't
attach to a Frame the way you can to an IE or Modal window.) My method
is designed to completely re-create the exact method string to get back
to the element to be clicked, and is working well for me right now,
though there are some inconsistencies with table related elements (which
is what got me looking at our current container/collection issue).
Right. The method in trunk handles click_no_wait in all watir objects except frames. It is impervious to how we've implemented support for most controls and therefore is unaffected by the issues you've raised with table elements. To my thinking, that makes this code more flexible than what is in the modal_dialog branch. We just need to add support for frames.
It's probably just two lines of code. I guess i can do it if you are uncomfortable with this approach.
It's at
https://svn.openqa.org/svn/watir/branches/modal_dialog/watir and
I'm doing lots of click_no_wait's from within frames. Feel free to
contact me if you have questions about the code in that branch as it's
pretty much my branch right now and it's probably a dead end until it's
decided to port that code to the current trunk.
What do we have in there that isn't already in trunk, other than the frame/click_no_wait support?
Bret
|
[1-6]
|
|