From bret at pettichord.com Mon Feb 1 11:06:59 2010 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 1 Feb 2010 10:06:59 -0600 Subject: [Wtr-development] New proposed Watir project home on the wiki In-Reply-To: <16bf298e1001312053h171518bdj33dd5e3b1ed257e4@mail.gmail.com> References: <16bf298e1001312053h171518bdj33dd5e3b1ed257e4@mail.gmail.com> Message-ID: I like to use the old page, but it doesn't have to be the first one that people see. Probably overload. Maybe we can call it the index page? Bret On Sun, Jan 31, 2010 at 10:53 PM, Alister Scott wrote: > Hi, > > Now that we have the latest version of Confluence, I was thinking of > updating the project home page on the wiki. > > I wanted to make it more dynamic, so I have come up with a proposal. > > The current page is: http://wiki.openqa.org/display/WTR/Project+Home > > The new proposed page is: > http://wiki.openqa.org/display/WTR/Project+Home+%28Proposed%29 > > Please take a look and let me know what you think, and what you think > could be better. > 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 > > _______________________________________________ > Wtr-development mailing list > Wtr-development at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Wed Feb 3 05:56:17 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 3 Feb 2010 11:56:17 +0100 Subject: [Wtr-development] [wtr-general] New proposed Watir project home on the wiki In-Reply-To: References: Message-ID: On Mon, Feb 1, 2010 at 5:32 AM, Alister Scott wrote: > The new proposed page is: http://wiki.openqa.org/display/WTR/Project+Home+%28Proposed%29 Alister, This is not how the things should be done. I just make the change and _then_ ask if people like it. :) There is no need for staging phase. Go ahead and make it wiki home page. I would remove contributors and recently edited pages from the home page, but leave it if you think it should be there. ?eljko -- watir.com - community manager watirpodcast.com - host -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Wed Feb 3 05:59:30 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 3 Feb 2010 11:59:30 +0100 Subject: [Wtr-development] Donate to Watir Message-ID: If you like the Watir project, you can make a donation. There is donate button at http://watir.com/. We have raised $370 this year. You can see list of donors and Bret's thank you note at http://pledgie.com/campaigns/2982 ?eljko -- watir.com - community manager watirpodcast.com - host -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Wed Feb 3 06:08:23 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 3 Feb 2010 12:08:23 +0100 Subject: [Wtr-development] Watir Podcast #31 Message-ID: Jari Bakken and Simon Stewart on Watir 2.0, Selenium and WebDriver, Celerity and HtmlUnit http://bit.ly/aNqUkU ?eljko -- watir.com - community manager watirpodcast.com - host -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Wed Feb 3 06:11:14 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 3 Feb 2010 12:11:14 +0100 Subject: [Wtr-development] Ads on watir.com In-Reply-To: References: Message-ID: On Sun, Jan 31, 2010 at 9:05 PM, Bret Pettichord wrote: > I think this number includes openqa.org and therefore the Watir wiki. Probably. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Wed Feb 3 06:23:55 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 3 Feb 2010 12:23:55 +0100 Subject: [Wtr-development] Ads on watir.com In-Reply-To: <16bf298e1001301849n256eb2edr655a37f2285f40c4@mail.gmail.com> References: <16bf298e1001301849n256eb2edr655a37f2285f40c4@mail.gmail.com> Message-ID: Hi Alister, Comments are inline. On Sun, Jan 31, 2010 at 3:49 AM, Alister Scott wrote: > I am personally against advertisements on watir.com, because I think it defeats the whole purpose of creating a kick-ass open source tool, if your main site for it has advertisements for commercial/proprietary automated testing tools You think people that come to watir.com will switch to commerciall tool if they see an add at watir.com? > Why is this thought even being raised? Are we short of money or something? What are the big costs we need money for? No big costs. Paul is paying for the domain, you for the wordpress.com, Bret is paying $20/month for watirbuild.com (not up at the moment). I think it would be great if we had some money. We could for example pay for your plane ticket and/or hotel the next time you come to AWTA. I have heard that open source projects do that all the time. Or we could do the same for Angrez or Sai, since I think their companies would not pay for the trip. It would depend on the money raised, but it would be great if we could pay somebody to work on the code one day a month/week (Bret, Charley, Jari...) or to pay you or somebody else to work a few days on the documentation. What if we raised enough money to pay somebody (or group of authors) to write a book on Watir and then publish it under creative commons or something like that? I am not suggesting we should pay people all the time, but I guess being paid just a bit would not hurt. I could be wrong. Strange things can happen when money is involved. That is why I would like to have an open discussion. > Even if we wanted to run ads on watir.com, we can't because we're using wordpress.com. We would need to migrate the blog to our own host and then pay hosting costs. It's a bit of a wasted effort in my honest opinion. I have a shared hosting account and I have plenty of room there. I guess I am not the only one that could do it, but I would be more than happy to host watir.com on my account and do all the work, if we decide to move. > I look forward to hearing others thoughts on this matter. Same here. If you are against it, I would not force it. It was just an idea. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Wed Feb 3 06:51:51 2010 From: alister.scott at gmail.com (Alister Scott) Date: Wed, 3 Feb 2010 21:51:51 +1000 Subject: [Wtr-development] [wtr-general] New proposed Watir project home on the wiki In-Reply-To: References: Message-ID: <16bf298e1002030351g5d8dcbc1kedbaa06e605bc429@mail.gmail.com> Thanks for your feedback. I have now made changes to the home page on the wiki. http://wiki.openqa.org/display/WTR/Project+Home Cheers, Alister Scott Brisbane, Australia On Wed, Feb 3, 2010 at 8:56 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Mon, Feb 1, 2010 at 5:32 AM, Alister Scott > wrote: > > The new proposed page is: > http://wiki.openqa.org/display/WTR/Project+Home+%28Proposed%29 > > Alister, > > This is not how the things should be done. I just make the change and > _then_ ask if people like it. :) > > There is no need for staging phase. Go ahead and make it wiki home page. > > I would remove contributors and recently edited pages from the home page, > but leave it if you think it should be there. > > > ?eljko > -- > watir.com - community manager > watirpodcast.com - host > > > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Wed Feb 3 07:02:59 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 3 Feb 2010 13:02:59 +0100 Subject: [Wtr-development] [wtr-general] Re: New proposed Watir project home on the wiki In-Reply-To: References: Message-ID: On Wed, Feb 3, 2010 at 12:52 PM, Alister Scott wrote: > I have made changes to the Watir wiki home page: > http://wiki.openqa.org/display/WTR/Project+Home Thanks Alister. Everything looks better after you work on it. :) ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Wed Feb 3 09:07:19 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 3 Feb 2010 15:07:19 +0100 Subject: [Wtr-development] Ads on watir.com In-Reply-To: References: <16bf298e1001301849n256eb2edr655a37f2285f40c4@mail.gmail.com> Message-ID: Found the post: "...Selenium continues to generate ~$1000/mo in advertisement revenues..." http://bit.ly/b7ycVA ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.m.stewart at gmail.com Wed Feb 3 10:53:58 2010 From: simon.m.stewart at gmail.com (Simon Stewart) Date: Wed, 3 Feb 2010 15:53:58 +0000 Subject: [Wtr-development] Ads on watir.com In-Reply-To: References: <16bf298e1001301849n256eb2edr655a37f2285f40c4@mail.gmail.com> Message-ID: <77aa50681002030753s8e8248fmd58babb8b86ae308@mail.gmail.com> As Brett says, that money is used to cover hosting costs, and to occasionally pay the airfare for team members who otherwise wouldn't be able to make a full meetup of the team. The xserve we use as our build server[1] was also paid for from the ad income. We also recently discussed making a charitable donation with some of the ad revenue. Simon [1] http://xserve.openqa.org:8085 On Wed, Feb 3, 2010 at 2:07 PM, ?eljko Filipin wrote: > Found the post: > > "...Selenium continues to generate ~$1000/mo in advertisement revenues..." > > http://bit.ly/b7ycVA > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From marekj.com at gmail.com Wed Feb 3 11:09:58 2010 From: marekj.com at gmail.com (marekj) Date: Wed, 3 Feb 2010 10:09:58 -0600 Subject: [Wtr-development] Fwd: watir.com/rdoc In-Reply-To: References: <2a379a301001092129q78155de2u6ddd271d23d5f21f@mail.gmail.com> Message-ID: I asked Tom to remove the files (done, thanks to Tom: http://rubyforge.org/forum/message.php?msg_id=92511) next: make nice index.html suggested by Zeljko instead of just raw dir listing marekj On Fri, Jan 29, 2010 at 4:08 AM, ?eljko Filipin wrote: > On Fri, Jan 29, 2010 at 5:07 AM, marekj wrote: >> anybody has any ideas how I can remove the old files? > > You can ask Tom Copeland (http://tomcopeland.blogs.com/) of Rubyforge. Let > me know if you need his e-mail. Rubyforge has a support tracker too, the > were pretty quick to reply when I had problems. Let me know if you can not > find it. > >> posted new docs >> http://wtr.rubyforge.org/rdoc/1.6.5/ > > Thanks! Looks great. :) > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From tim.koops at gmail.com Thu Feb 4 17:34:24 2010 From: tim.koops at gmail.com (Tim Koopmans) Date: Fri, 5 Feb 2010 09:34:24 +1100 Subject: [Wtr-development] watirgrid In-Reply-To: References: <93ee69e91002031614h6f1b0437g58a14bbe4508ccfc@mail.gmail.com> Message-ID: <93ee69e91002041434l35afd85oc9c9137b91791f8@mail.gmail.com> Great stuff Josh! Glad it's working out ok. I've done some limited testing with up to 10 EC2 instances running firefox... Competing product is Selenium Grid as you've mentioned. I'm also procrastinating on the integration of Stella[1] into the grid providers. I've let people know of Watirgrid on the development group. Not yet to watir-general. I'll copy this thread to watir-dev. Feel free to ask on watir-general. Might be good to have other people's viewpoint on the usefulness of this implementation of Watir. As for using Watir, I'm a performance tester by day so work mostly with LoadRunner and JMeter. I'm looking to tools like Watirgrid (browser based) and Stella (protocol based) to alleviate the pain of writing load tests in C and/or vendorscripts... Regards, Tim Koopmans http://watirgrid.com [1] http://solutious.com/projects/stella/getting-started/ On Fri, Feb 5, 2010 at 9:10 AM, joshua wallis wrote: > Just did a proof of concept on two machines at work. It works great so > far! I'm not sure yet how I'm going to fit it into my framework but at this > point I'd really like to. > > So I don't get why people aren't all over this...? Is there a "competing" > utility? Selenium people obviously realize the need for it, hence "selenium > grid." > How much do you actually use Watir? It's been my whole job the past couple > months and I'm hoping to build a large regression suite for my co. Have you > shown this to the watir google group? I really want to ask people why > they're not all over it... > > -j > > > > > On Wed, Feb 3, 2010 at 7:24 PM, joshua wallis wrote: > >> Cool. Gonna play with it some then I'll probably have more questions... >> >> Thanks, >> -j >> >> >> On Wed, Feb 3, 2010 at 6:14 PM, Tim Koopmans wrote: >> >>> Hi Josh, >>> >>> Firstly thanks for the interest, I haven't had many others test/use the >>> code that I know of so far =) >>> >>> Watirgrid is built on Rinda, which itself sits on top of DRb. >>> >>> So to answer your first question, a DRb 'front' object is instantiated on >>> each remote provider. Normally when an object is returned by a method called >>> over DRb, the object is marshaled, sent over the connection, and run on the >>> client side. You'll notice in the provider class I include DRbUndumped into >>> it which tells DRb that the object cannot be marshaled and that DRb should >>> send a reference to it instead. The object then stays on the provider side, >>> and the reference on the client side then proxies the method calls back and >>> forth to the server. Rinda just allows me to run a ring server (which is the >>> controller) which makes it easier to advertise what services (tuples) each >>> different provider are providing, and facilitates the communication between >>> your client and the remote providers. >>> >>> The client code e.g. >>> >>> grid.browsers.each do |browser| >>> threads << Thread.new do >>> b = browser[:object].new_browser >>> >>> >>> >>> b.goto("http://www.google.com") >>> >>> >>> b.text_field(:name, 'q').set("watirgrid") >>> b.button(:name, "btnI").click >>> end >>> end >>> >>> uses threads to send commands to all the browser front objects in the >>> grid (providers). In this case I didn't have a cool way to effectively >>> notify X providers to execute the code concurrently, so am just using Ruby >>> threads for time being until I figure out a better way. I'm not sure how >>> this might scale, but as all the processing is being done remotely on the >>> providers (by reference), I'm fairly sure it will have a light impact. >>> >>> Hope that helps/makes sense! >>> >>> Regards, >>> Tim Koopmans >>> >>> >>> >>> >>> On Thu, Feb 4, 2010 at 10:52 AM, joshua wallis wrote: >>> >>>> Tim, >>>> I have been developing my watir framework and am getting to the point >>>> where I'm going to need distribution of testcases across machines and I'm >>>> wondering if watirGrid is right for me. I've read a few of your github >>>> files and I have a few questions on the Readme: >>>> >>>> you say, after starting the controller and providers: >>>> >>>> You will now be able to execute commands across remote browsers on your >>>> grid network. >>>> >>>> e.g. >>>> >>>> grid = Watir::Grid.new(:ring_server_port => 12358) >>>> grid.start(:quantity => 1, :read_all => true) >>>> threads = [] >>>> >>>> grid.browsers.each do |browser| >>>> threads << Thread.new do >>>> b = browser[:object].new_browser >>>> b.goto("http://www.google.com") >>>> >>>> >>>> >>>> >>>> >>>> >>>> b.text_field(:name, 'q').set("watirgrid") >>>> b.button(:name, "btnI").click >>>> end >>>> end >>>> >>>> threads.each {|thread| thread.join} >>>> >>>> >>>> >>>> >>>> >>>> So I?m curious about where the objects live. I would expect that the >>>> each provider creates a water object when it?s started, then registers the >>>> Waitr obj with the controller. But in the above piece of code it looks >>>> like the controller is creating a local thread for each provider and >>>> creating new browser objects (which I assume is a wrapper for a Watir >>>> object). Maybe this is typical Rinda usage and I?ve just never seen it >>>> before. Are the threads actually local ?hard-working? threads or just >>>> placeholders for the threads on the providers which are used to coordinate >>>> when all providers are finished? >>>> >>>> >>>> >>>> Thanks for any info you can give me, >>>> >>>> -Josh >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Fri Feb 5 07:13:34 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 5 Feb 2010 13:13:34 +0100 Subject: [Wtr-development] Watir ads at stackoverflow.com In-Reply-To: References: Message-ID: Want to see Watir ads on stackoverflow.com? This answer needs five upvotes. Current status: 0/5. http://bit.ly/djPPfj ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Fri Feb 5 15:50:34 2010 From: bret at pettichord.com (Bret Pettichord) Date: Fri, 5 Feb 2010 14:50:34 -0600 Subject: [Wtr-development] Watir ads at stackoverflow.com In-Reply-To: References: Message-ID: Zeljko, It seems to me that the Watir entry does not meet the stated requirements. It must be an advertisement *soliciting the participation and contribution > of programmers writing actual source code*. This is not intended as a > general purpose ad for consumer products which just happen to be open > source. It's for finding programmers who will help contribute code or other > programmery things (documentation, code review, bugfixes, etc). > Rather it is just a logo. If we get more contributors, do we have a to do list we can point them to? Bret On Fri, Feb 5, 2010 at 6:13 AM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > Want to see Watir ads on stackoverflow.com? This answer needs five > upvotes. Current status: 0/5. http://bit.ly/djPPfj > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Fri Feb 5 16:58:55 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Fri, 5 Feb 2010 22:58:55 +0100 Subject: [Wtr-development] Watir ads at stackoverflow.com In-Reply-To: References: Message-ID: On Fri, Feb 5, 2010 at 9:50 PM, Bret Pettichord wrote: > It seems to me that the Watir entry does not meet the stated requirements. >> It must be an advertisement soliciting the participation and contribution of programmers writing actual source code. > Rather it is just a logo. I suck in visual design. I only had the time to cut the watir logo from watir.com and resize it. I can edit the image if somebody adds some text to it. (Alister?) I have provided this text with the image: "Watir, automated testing that doesn?t hurt. Looking for developers." I thought it will display as tool tip. > If we get more contributors, do we have a to do list we can point them to? The image is a link to watir.com. I think our community page explains how to contribute well enough. Maybe it should be updated with watir-webdriver. To sum up, if my answer does not get 5 upvotes, the ad will not be displayed, so we can just ignore it. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Fri Feb 5 18:49:42 2010 From: bret at pettichord.com (Bret Pettichord) Date: Fri, 5 Feb 2010 17:49:42 -0600 Subject: [Wtr-development] Watir ads at stackoverflow.com In-Reply-To: References: Message-ID: On Fri, Feb 5, 2010 at 3:58 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > I have provided this text with the image: "Watir, automated testing that > doesn?t hurt. Looking for developers." I thought it will display as tool > tip. > Something went wrong with this. I see the tool tip for the Rails entry, but not for the Watir entry. Can you edit it or do you need to resubmit? Bret Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Sat Feb 6 17:17:24 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Sat, 6 Feb 2010 23:17:24 +0100 Subject: [Wtr-development] Watir ads at stackoverflow.com In-Reply-To: References: Message-ID: On Sat, Feb 6, 2010 at 12:49 AM, Bret Pettichord wrote: > Something went wrong with this. I see the tool tip for the Rails entry, but not for the Watir entry. Can you edit it or do you need to resubmit? I took a look how Rails code looks. I guess they know markdown better that I do. :) I have changed [2]: http://watir.com/ to [2]: http://watir.com/ "Watir, automated testing that doesn?t hurt. Looking for developers." and now we have a tool tip. And we have two upvotes (2/5). Three to go. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Mon Feb 8 04:32:27 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 8 Feb 2010 10:32:27 +0100 Subject: [Wtr-development] Watir ads at stackoverflow.com In-Reply-To: References: Message-ID: On Fri, Feb 5, 2010 at 1:13 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > Want to see Watir ads on stackoverflow.com? This answer needs five upvotes. Current status: 0/5. http://bit.ly/djPPfj Current status: 3/5 (60%). Two more votes. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From marekj.com at gmail.com Mon Feb 8 11:51:43 2010 From: marekj.com at gmail.com (marekj) Date: Mon, 8 Feb 2010 10:51:43 -0600 Subject: [Wtr-development] Fwd: watir.com/rdoc In-Reply-To: References: Message-ID: Proposal on New direction after speaking with Bret. I think that the rdoc for the watir project should include all 3 gems, watir, firewatir and commonwatir This is the rdoc we should display at wtr.rubyforge.org/rdoc Then for each individual gem the rdoc created locally by each user will reflect only that particular gem library. marekj Watirloo: Semantic Page Objects in UseCases http://github.com/marekj/watirloo/ Support Watir Project http://pledgie.com/campaigns/2982 On Wed, Feb 3, 2010 at 10:09 AM, marekj wrote: > I asked Tom to remove the files (done, thanks to Tom: > http://rubyforge.org/forum/message.php?msg_id=92511) > next: make nice index.html suggested by Zeljko instead of just raw dir listing > > > marekj > > > > > On Fri, Jan 29, 2010 at 4:08 AM, ?eljko Filipin > wrote: >> On Fri, Jan 29, 2010 at 5:07 AM, marekj wrote: >>> anybody has any ideas how I can remove the old files? >> >> You can ask Tom Copeland (http://tomcopeland.blogs.com/) of Rubyforge. Let >> me know if you need his e-mail. Rubyforge has a support tracker too, the >> were pretty quick to reply when I had problems. Let me know if you can not >> find it. >> >>> posted new docs >>> http://wtr.rubyforge.org/rdoc/1.6.5/ >> >> Thanks! Looks great. :) >> >> ?eljko >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > From zeljko.filipin at wa-research.ch Mon Feb 8 12:05:32 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 8 Feb 2010 18:05:32 +0100 Subject: [Wtr-development] Fwd: watir.com/rdoc In-Reply-To: References: Message-ID: On Mon, Feb 8, 2010 at 5:51 PM, marekj wrote: > I think that the rdoc for the watir project should include all 3 gems, > watir, firewatir and commonwatir Sounds good to me. ?eljko -- watir.com - community manager pledgie.com/campaigns/2982 - donate to Watir watirpodcast.com - host testingpodcast.com - podcasts on software testing. all of them -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Mon Feb 8 11:44:08 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 8 Feb 2010 17:44:08 +0100 Subject: [Wtr-development] Watir ads at stackoverflow.com In-Reply-To: References: Message-ID: Thanks to everybody that voted (or tried to vote) for Watir ad on stackoverflow.com! Current status: 5/5 = 100% :) http://bit.ly/djPPfj ?eljko -- watir.com - community manager watirpodcast.com - host pledgie.com/campaigns/2982 - donate to Watir -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Tue Feb 9 05:44:17 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 9 Feb 2010 11:44:17 +0100 Subject: [Wtr-development] Watir ads at stackoverflow.com In-Reply-To: References: Message-ID: Watir ad at stackoverflow.com! :) http://bit.ly/cPmfFn ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Tue Feb 9 11:25:22 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 9 Feb 2010 17:25:22 +0100 Subject: [Wtr-development] OT: Testing Podcast Message-ID: If you listen to Watir Podcast, maybe Testing Podcast site will be of interest to you. All audio files on software testing in one place: http://testingpodcast.com/ Feel free to spread the word. If you use Twitter, you can use #TestingPodcast hash tag: http://twitter.com/#search?q=%23TestingPodcast If I missed software testing related mp3 or even a whole podcast, please let me know. ?eljko -- watir.com - community manager pledgie.com/campaigns/2982 - donate to Watir watirpodcast.com - host testingpodcast.com - podcasts on software testing. all of them -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathamberlane at gmail.com Tue Feb 9 13:11:06 2010 From: nathamberlane at gmail.com (Nathan Lane) Date: Tue, 9 Feb 2010 11:11:06 -0700 Subject: [Wtr-development] Tried to run unit tests Message-ID: <9afbd5b91002091011y47940099w75a4418ce25d376a@mail.gmail.com> Alright, I was going to run the unit tests for Watir 1.6, but I keep getting an unusual error. I don't understand it. I do understand what is failing. I'm looking into it more, but so far I haven't gotten anywhere. It has been a loooong time since I ran the Watir unit tests, and so maybe something is wrong in my process. So here is what I have done: 1. Install the Watir and associated gems 2. Change to the Watir gem directory (on my system C:\Ruby19\lib\ruby\gems\1.9.1\gems\watir-1.6.5) 3. Run .\unittests\all_tests.rb And the result in PowerShell is: C:/Ruby19/lib/ruby/gems/1.9.1/gems/watir-1.6.5/unittests/setup.rb:21:in `require': no such file to load -- unittests/setup/lib (LoadError) from C:/Ruby19/lib/ruby/gems/1.9.1/gems/watir-1.6.5/unittests/setup.rb:21:in `' from C:/Ruby19/lib/ruby/gems/1.9.1/gems/watir-1.6.5/unittests/all_tests.rb:4:in `require' from C:/Ruby19/lib/ruby/gems/1.9.1/gems/watir-1.6.5/unittests/all_tests.rb:4:in `
' I have also tried running from inside of the unittests directory, and I get the same error. Now realizing that the error actually might have something to do with paths, I noticed that I don't have a setup or setup/lib folder in the folder structure under the unittests folder. What I have is this: PS C:\Ruby19\lib\ruby\gems\1.9.1\gems\watir-1.6.5> ls Directory: Microsoft.PowerShell.Core\FileSystem::C:\Ruby19\lib\ruby\gems\1.9.1\gems\watir-1.6.5 Mode LastWriteTime Length Name ---- ------------- ------ ---- d---- 2/9/2010 11:01 AM bin d---- 2/9/2010 11:01 AM lib d---- 2/9/2010 11:01 AM unittests -a--- 2/9/2010 11:01 AM 15666 CHANGES and under unittests I have: PS C:\Ruby19\lib\ruby\gems\1.9.1\gems\watir-1.6.5\unittests> ls Directory: Microsoft.PowerShell.Core\FileSystem::C:\Ruby19\lib\ruby\gems\1.9.1\gems\watir-1.6.5\unittests Mode LastWriteTime Length Name ---- ------------- ------ ---- d---- 2/9/2010 11:01 AM html d---- 2/9/2010 11:01 AM other d---- 2/9/2010 11:01 AM windows -a--- 2/9/2010 11:01 AM 158 all_tests.rb -a--- 2/9/2010 11:01 AM 3255 buttons_xpath_test.rb -a--- 2/9/2010 11:01 AM 7044 checkbox_test.rb -a--- 2/9/2010 11:01 AM 5680 checkbox_xpath_test.rb -a--- 2/9/2010 11:01 AM 372 core_tests.rb -a--- 2/9/2010 11:01 AM 738 css_test.rb -a--- 2/9/2010 11:01 AM 1770 defer_test.rb -a--- 2/9/2010 11:01 AM 2123 dialog_test.rb -a--- 2/9/2010 11:01 AM 842 div2_xpath_test.rb -a--- 2/9/2010 11:01 AM 7953 div_test.rb -a--- 2/9/2010 11:01 AM 4980 div_xpath_test.rb -a--- 2/9/2010 11:01 AM 649 errorchecker_test.rb -a--- 2/9/2010 11:01 AM 1087 filefield_test.rb -a--- 2/9/2010 11:01 AM 1061 filefield_xpath_test.rb -a--- 2/9/2010 11:01 AM 9871 form_test.rb -a--- 2/9/2010 11:01 AM 8758 form_xpath_test.rb -a--- 2/9/2010 11:01 AM 5509 frame_test.rb -a--- 2/9/2010 11:01 AM 370 google_form_test.rb -a--- 2/9/2010 11:01 AM 688 ie_exists_test.rb -a--- 2/9/2010 11:01 AM 1172 ie_mock.rb -a--- 2/9/2010 11:01 AM 1324 ie_test.rb -a--- 2/9/2010 11:01 AM 6409 images_test.rb -a--- 2/9/2010 11:01 AM 3852 images_xpath_test.rb -a--- 2/9/2010 11:01 AM 1443 links_multi_test.rb -a--- 2/9/2010 11:01 AM 6860 links_test.rb -a--- 2/9/2010 11:01 AM 1242 links_xpath_test.rb -a--- 2/9/2010 11:01 AM 818 lists_test.rb -a--- 2/9/2010 11:01 AM 3333 map_test.rb -a--- 2/9/2010 11:01 AM 664 minmax_test.rb -a--- 2/9/2010 11:01 AM 1258 navigate_test.rb -a--- 2/9/2010 11:01 AM 372 nbsp_xpath_test.rb -a--- 2/9/2010 11:01 AM 279 non_core_tests.rb -a--- 2/9/2010 11:01 AM 1697 pagecontainstext_test.rb -a--- 2/9/2010 11:01 AM 1423 parent_child_test.rb -a--- 2/9/2010 11:01 AM 703 perf_test.rb -a--- 2/9/2010 11:01 AM 1102 popups_test.rb -a--- 2/9/2010 11:01 AM 1600 pre_test.rb -a--- 2/9/2010 11:01 AM 8247 radios_test.rb -a--- 2/9/2010 11:01 AM 4589 radios_xpath_test.rb -a--- 2/9/2010 11:01 AM 819 security_setting_test.rb -a--- 2/9/2010 11:01 AM 6113 selectbox_test.rb -a--- 2/9/2010 11:01 AM 5801 selectbox_xpath_test.rb -a--- 2/9/2010 11:01 AM 2061 setup.rb -a--- 2/9/2010 11:01 AM 1722 speed_settings_test.rb -a--- 2/9/2010 11:01 AM 1539 table_cell_using_xpath_test.rb -a--- 2/9/2010 11:01 AM 12436 table_test.rb -a--- 2/9/2010 11:01 AM 3780 table_xpath_test.rb -a--- 2/9/2010 11:01 AM 198 test_tests.rb -a--- 2/9/2010 11:01 AM 3253 textarea_test.rb -a--- 2/9/2010 11:01 AM 5132 textarea_xpath_test.rb -a--- 2/9/2010 11:01 AM 9510 textfields_test.rb -a--- 2/9/2010 11:01 AM 6523 textfields_xpath_test.rb -a--- 2/9/2010 11:01 AM 1047 textfield_for_ch_char_test.rb -a--- 2/9/2010 11:01 AM 190 window_tests.rb -a--- 2/9/2010 11:01 AM 221 xpath_tests.rb Any advice? Or is this a defect? Thanks. -- Nathan Lane Blog, http://blog.nathandelane.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Tue Feb 9 14:08:56 2010 From: bret at pettichord.com (Bret Pettichord) Date: Tue, 9 Feb 2010 13:08:56 -0600 Subject: [Wtr-development] Tried to run unit tests In-Reply-To: <9afbd5b91002091011y47940099w75a4418ce25d376a@mail.gmail.com> References: <9afbd5b91002091011y47940099w75a4418ce25d376a@mail.gmail.com> Message-ID: The unit tests are no longer designed to be run from an installed gem. It is a bug that they are still packaged with the gem. If you want to run the unit tests, you should check out the code from git, and then run them from your development workspace. Bret On Tue, Feb 9, 2010 at 12:11 PM, Nathan Lane wrote: > Alright, I was going to run the unit tests for Watir 1.6, but I keep > getting an unusual error. I don't understand it. I do understand what is > failing. I'm looking into it more, but so far I haven't gotten anywhere. It > has been a loooong time since I ran the Watir unit tests, and so maybe > something is wrong in my process. So here is what I have done: > > 1. Install the Watir and associated gems > 2. Change to the Watir gem directory (on my > system C:\Ruby19\lib\ruby\gems\1.9.1\gems\watir-1.6.5) > 3. Run .\unittests\all_tests.rb > > And the result in PowerShell is: > > C:/Ruby19/lib/ruby/gems/1.9.1/gems/watir-1.6.5/unittests/setup.rb:21:in > `require': no such file to load -- unittests/setup/lib (LoadError) > from > C:/Ruby19/lib/ruby/gems/1.9.1/gems/watir-1.6.5/unittests/setup.rb:21:in > `' > from > C:/Ruby19/lib/ruby/gems/1.9.1/gems/watir-1.6.5/unittests/all_tests.rb:4:in > `require' > from > C:/Ruby19/lib/ruby/gems/1.9.1/gems/watir-1.6.5/unittests/all_tests.rb:4:in > `
' > > I have also tried running from inside of the unittests directory, and I get > the same error. Now realizing that the error actually might have something > to do with paths, I noticed that I don't have a setup or setup/lib folder in > the folder structure under the unittests folder. What I have is this: > > PS C:\Ruby19\lib\ruby\gems\1.9.1\gems\watir-1.6.5> ls > > > Directory: > Microsoft.PowerShell.Core\FileSystem::C:\Ruby19\lib\ruby\gems\1.9.1\gems\watir-1.6.5 > > > Mode LastWriteTime Length Name > ---- ------------- ------ ---- > d---- 2/9/2010 11:01 AM bin > d---- 2/9/2010 11:01 AM lib > d---- 2/9/2010 11:01 AM unittests > -a--- 2/9/2010 11:01 AM 15666 CHANGES > > and under unittests I have: > > PS C:\Ruby19\lib\ruby\gems\1.9.1\gems\watir-1.6.5\unittests> ls > > > Directory: > Microsoft.PowerShell.Core\FileSystem::C:\Ruby19\lib\ruby\gems\1.9.1\gems\watir-1.6.5\unittests > > > Mode LastWriteTime Length Name > ---- ------------- ------ ---- > d---- 2/9/2010 11:01 AM html > d---- 2/9/2010 11:01 AM other > d---- 2/9/2010 11:01 AM windows > -a--- 2/9/2010 11:01 AM 158 all_tests.rb > -a--- 2/9/2010 11:01 AM 3255 buttons_xpath_test.rb > -a--- 2/9/2010 11:01 AM 7044 checkbox_test.rb > -a--- 2/9/2010 11:01 AM 5680 checkbox_xpath_test.rb > -a--- 2/9/2010 11:01 AM 372 core_tests.rb > -a--- 2/9/2010 11:01 AM 738 css_test.rb > -a--- 2/9/2010 11:01 AM 1770 defer_test.rb > -a--- 2/9/2010 11:01 AM 2123 dialog_test.rb > -a--- 2/9/2010 11:01 AM 842 div2_xpath_test.rb > -a--- 2/9/2010 11:01 AM 7953 div_test.rb > -a--- 2/9/2010 11:01 AM 4980 div_xpath_test.rb > -a--- 2/9/2010 11:01 AM 649 errorchecker_test.rb > -a--- 2/9/2010 11:01 AM 1087 filefield_test.rb > -a--- 2/9/2010 11:01 AM 1061 filefield_xpath_test.rb > -a--- 2/9/2010 11:01 AM 9871 form_test.rb > -a--- 2/9/2010 11:01 AM 8758 form_xpath_test.rb > -a--- 2/9/2010 11:01 AM 5509 frame_test.rb > -a--- 2/9/2010 11:01 AM 370 google_form_test.rb > -a--- 2/9/2010 11:01 AM 688 ie_exists_test.rb > -a--- 2/9/2010 11:01 AM 1172 ie_mock.rb > -a--- 2/9/2010 11:01 AM 1324 ie_test.rb > -a--- 2/9/2010 11:01 AM 6409 images_test.rb > -a--- 2/9/2010 11:01 AM 3852 images_xpath_test.rb > -a--- 2/9/2010 11:01 AM 1443 links_multi_test.rb > -a--- 2/9/2010 11:01 AM 6860 links_test.rb > -a--- 2/9/2010 11:01 AM 1242 links_xpath_test.rb > -a--- 2/9/2010 11:01 AM 818 lists_test.rb > -a--- 2/9/2010 11:01 AM 3333 map_test.rb > -a--- 2/9/2010 11:01 AM 664 minmax_test.rb > -a--- 2/9/2010 11:01 AM 1258 navigate_test.rb > -a--- 2/9/2010 11:01 AM 372 nbsp_xpath_test.rb > -a--- 2/9/2010 11:01 AM 279 non_core_tests.rb > -a--- 2/9/2010 11:01 AM 1697 pagecontainstext_test.rb > -a--- 2/9/2010 11:01 AM 1423 parent_child_test.rb > -a--- 2/9/2010 11:01 AM 703 perf_test.rb > -a--- 2/9/2010 11:01 AM 1102 popups_test.rb > -a--- 2/9/2010 11:01 AM 1600 pre_test.rb > -a--- 2/9/2010 11:01 AM 8247 radios_test.rb > -a--- 2/9/2010 11:01 AM 4589 radios_xpath_test.rb > -a--- 2/9/2010 11:01 AM 819 security_setting_test.rb > -a--- 2/9/2010 11:01 AM 6113 selectbox_test.rb > -a--- 2/9/2010 11:01 AM 5801 selectbox_xpath_test.rb > -a--- 2/9/2010 11:01 AM 2061 setup.rb > -a--- 2/9/2010 11:01 AM 1722 speed_settings_test.rb > -a--- 2/9/2010 11:01 AM 1539 table_cell_using_xpath_test.rb > -a--- 2/9/2010 11:01 AM 12436 table_test.rb > -a--- 2/9/2010 11:01 AM 3780 table_xpath_test.rb > -a--- 2/9/2010 11:01 AM 198 test_tests.rb > -a--- 2/9/2010 11:01 AM 3253 textarea_test.rb > -a--- 2/9/2010 11:01 AM 5132 textarea_xpath_test.rb > -a--- 2/9/2010 11:01 AM 9510 textfields_test.rb > -a--- 2/9/2010 11:01 AM 6523 textfields_xpath_test.rb > -a--- 2/9/2010 11:01 AM 1047 textfield_for_ch_char_test.rb > -a--- 2/9/2010 11:01 AM 190 window_tests.rb > -a--- 2/9/2010 11:01 AM 221 xpath_tests.rb > > Any advice? Or is this a defect? > > Thanks. > > -- > Nathan Lane > Blog, http://blog.nathandelane.com > > _______________________________________________ > Wtr-development mailing list > Wtr-development at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathamberlane at gmail.com Tue Feb 9 14:16:30 2010 From: nathamberlane at gmail.com (Nathan Lane) Date: Tue, 9 Feb 2010 12:16:30 -0700 Subject: [Wtr-development] Tried to run unit tests In-Reply-To: References: <9afbd5b91002091011y47940099w75a4418ce25d376a@mail.gmail.com> Message-ID: <9afbd5b91002091116m6fe19afcj8388da97c9e11339@mail.gmail.com> Thank you both. I will get the code from git. And install test-unit. On Tue, Feb 9, 2010 at 12:08 PM, Bret Pettichord wrote: > The unit tests are no longer designed to be run from an installed gem. It > is a bug that they are still packaged with the gem. > > If you want to run the unit tests, you should check out the code from git, > and then run them from your development workspace. > > Bret > > On Tue, Feb 9, 2010 at 12:11 PM, Nathan Lane wrote: > >> Alright, I was going to run the unit tests for Watir 1.6, but I keep >> getting an unusual error. I don't understand it. I do understand what is >> failing. I'm looking into it more, but so far I haven't gotten anywhere. It >> has been a loooong time since I ran the Watir unit tests, and so maybe >> something is wrong in my process. So here is what I have done: >> >> 1. Install the Watir and associated gems >> 2. Change to the Watir gem directory (on my >> system C:\Ruby19\lib\ruby\gems\1.9.1\gems\watir-1.6.5) >> 3. Run .\unittests\all_tests.rb >> >> And the result in PowerShell is: >> >> C:/Ruby19/lib/ruby/gems/1.9.1/gems/watir-1.6.5/unittests/setup.rb:21:in >> `require': no such file to load -- unittests/setup/lib (LoadError) >> from >> C:/Ruby19/lib/ruby/gems/1.9.1/gems/watir-1.6.5/unittests/setup.rb:21:in >> `' >> from >> C:/Ruby19/lib/ruby/gems/1.9.1/gems/watir-1.6.5/unittests/all_tests.rb:4:in >> `require' >> from >> C:/Ruby19/lib/ruby/gems/1.9.1/gems/watir-1.6.5/unittests/all_tests.rb:4:in >> `
' >> >> I have also tried running from inside of the unittests directory, and I >> get the same error. Now realizing that the error actually might have >> something to do with paths, I noticed that I don't have a setup or setup/lib >> folder in the folder structure under the unittests folder. What I have is >> this: >> >> PS C:\Ruby19\lib\ruby\gems\1.9.1\gems\watir-1.6.5> ls >> >> >> Directory: >> Microsoft.PowerShell.Core\FileSystem::C:\Ruby19\lib\ruby\gems\1.9.1\gems\watir-1.6.5 >> >> >> Mode LastWriteTime Length Name >> ---- ------------- ------ ---- >> d---- 2/9/2010 11:01 AM bin >> d---- 2/9/2010 11:01 AM lib >> d---- 2/9/2010 11:01 AM unittests >> -a--- 2/9/2010 11:01 AM 15666 CHANGES >> >> and under unittests I have: >> >> PS C:\Ruby19\lib\ruby\gems\1.9.1\gems\watir-1.6.5\unittests> ls >> >> >> Directory: >> Microsoft.PowerShell.Core\FileSystem::C:\Ruby19\lib\ruby\gems\1.9.1\gems\watir-1.6.5\unittests >> >> >> Mode LastWriteTime Length Name >> ---- ------------- ------ ---- >> d---- 2/9/2010 11:01 AM html >> d---- 2/9/2010 11:01 AM other >> d---- 2/9/2010 11:01 AM windows >> -a--- 2/9/2010 11:01 AM 158 all_tests.rb >> -a--- 2/9/2010 11:01 AM 3255 buttons_xpath_test.rb >> -a--- 2/9/2010 11:01 AM 7044 checkbox_test.rb >> -a--- 2/9/2010 11:01 AM 5680 checkbox_xpath_test.rb >> -a--- 2/9/2010 11:01 AM 372 core_tests.rb >> -a--- 2/9/2010 11:01 AM 738 css_test.rb >> -a--- 2/9/2010 11:01 AM 1770 defer_test.rb >> -a--- 2/9/2010 11:01 AM 2123 dialog_test.rb >> -a--- 2/9/2010 11:01 AM 842 div2_xpath_test.rb >> -a--- 2/9/2010 11:01 AM 7953 div_test.rb >> -a--- 2/9/2010 11:01 AM 4980 div_xpath_test.rb >> -a--- 2/9/2010 11:01 AM 649 errorchecker_test.rb >> -a--- 2/9/2010 11:01 AM 1087 filefield_test.rb >> -a--- 2/9/2010 11:01 AM 1061 filefield_xpath_test.rb >> -a--- 2/9/2010 11:01 AM 9871 form_test.rb >> -a--- 2/9/2010 11:01 AM 8758 form_xpath_test.rb >> -a--- 2/9/2010 11:01 AM 5509 frame_test.rb >> -a--- 2/9/2010 11:01 AM 370 google_form_test.rb >> -a--- 2/9/2010 11:01 AM 688 ie_exists_test.rb >> -a--- 2/9/2010 11:01 AM 1172 ie_mock.rb >> -a--- 2/9/2010 11:01 AM 1324 ie_test.rb >> -a--- 2/9/2010 11:01 AM 6409 images_test.rb >> -a--- 2/9/2010 11:01 AM 3852 images_xpath_test.rb >> -a--- 2/9/2010 11:01 AM 1443 links_multi_test.rb >> -a--- 2/9/2010 11:01 AM 6860 links_test.rb >> -a--- 2/9/2010 11:01 AM 1242 links_xpath_test.rb >> -a--- 2/9/2010 11:01 AM 818 lists_test.rb >> -a--- 2/9/2010 11:01 AM 3333 map_test.rb >> -a--- 2/9/2010 11:01 AM 664 minmax_test.rb >> -a--- 2/9/2010 11:01 AM 1258 navigate_test.rb >> -a--- 2/9/2010 11:01 AM 372 nbsp_xpath_test.rb >> -a--- 2/9/2010 11:01 AM 279 non_core_tests.rb >> -a--- 2/9/2010 11:01 AM 1697 pagecontainstext_test.rb >> -a--- 2/9/2010 11:01 AM 1423 parent_child_test.rb >> -a--- 2/9/2010 11:01 AM 703 perf_test.rb >> -a--- 2/9/2010 11:01 AM 1102 popups_test.rb >> -a--- 2/9/2010 11:01 AM 1600 pre_test.rb >> -a--- 2/9/2010 11:01 AM 8247 radios_test.rb >> -a--- 2/9/2010 11:01 AM 4589 radios_xpath_test.rb >> -a--- 2/9/2010 11:01 AM 819 security_setting_test.rb >> -a--- 2/9/2010 11:01 AM 6113 selectbox_test.rb >> -a--- 2/9/2010 11:01 AM 5801 selectbox_xpath_test.rb >> -a--- 2/9/2010 11:01 AM 2061 setup.rb >> -a--- 2/9/2010 11:01 AM 1722 speed_settings_test.rb >> -a--- 2/9/2010 11:01 AM 1539 >> table_cell_using_xpath_test.rb >> -a--- 2/9/2010 11:01 AM 12436 table_test.rb >> -a--- 2/9/2010 11:01 AM 3780 table_xpath_test.rb >> -a--- 2/9/2010 11:01 AM 198 test_tests.rb >> -a--- 2/9/2010 11:01 AM 3253 textarea_test.rb >> -a--- 2/9/2010 11:01 AM 5132 textarea_xpath_test.rb >> -a--- 2/9/2010 11:01 AM 9510 textfields_test.rb >> -a--- 2/9/2010 11:01 AM 6523 textfields_xpath_test.rb >> -a--- 2/9/2010 11:01 AM 1047 textfield_for_ch_char_test.rb >> -a--- 2/9/2010 11:01 AM 190 window_tests.rb >> -a--- 2/9/2010 11:01 AM 221 xpath_tests.rb >> >> Any advice? Or is this a defect? >> >> Thanks. >> >> -- >> Nathan Lane >> Blog, http://blog.nathandelane.com >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Nathan Lane Blog, http://blog.nathandelane.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Thu Feb 11 09:10:55 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 11 Feb 2010 15:10:55 +0100 Subject: [Wtr-development] Watir Podcast #32 Message-ID: Next Saturday I am recording Watir Podcast #32 with Brent Strange and Gregg Yows. We will spend the most of the time talking about Brent's blog post "Testing in 2009, a Year in Review": http://bit.ly/cOUdC8 I would like to add a few minutes of Watir news at the beginning of the show. I have a few ideas, but I would like to hear what the community thinks was important in the last month in the Watir world, or if something important will happen in the next month. Conferences, blog posts, new gems released... Of course, if you have a question for Brent (also for Gregg or for me), ask. ?eljko -- watir.com - community manager pledgie.com/campaigns/2982 - donate to Watir watirpodcast.com - host testingpodcast.com - podcasts on software testing. all of them -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Thu Feb 11 15:12:27 2010 From: notethan at gmail.com (Ethan) Date: Thu, 11 Feb 2010 15:12:27 -0500 Subject: [Wtr-development] NoStatusBarException Message-ID: In unittests/other/js_events_test.rb, NoStatusBarException is expected to be raised when calling #status on a browser window with no visible status bar. Is this currently correct? I do not see NoStatusBarException being raised anywhere; IE#status simply returns @ie.statusText. Should the test be updated? From bret at pettichord.com Thu Feb 11 23:14:54 2010 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 11 Feb 2010 22:14:54 -0600 Subject: [Wtr-development] NoStatusBarException In-Reply-To: References: Message-ID: I can't find that test. Could you post a link to the file in github? Bret On Thu, Feb 11, 2010 at 2:12 PM, Ethan wrote: > In unittests/other/js_events_test.rb, NoStatusBarException is expected > to be raised when calling #status on a browser window with no visible > status bar. Is this currently correct? I do not see > NoStatusBarException being raised anywhere; IE#status simply returns > @ie.statusText. > Should the test be updated? > _______________________________________________ > Wtr-development mailing list > Wtr-development at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Thu Feb 11 23:24:55 2010 From: notethan at gmail.com (Ethan) Date: Thu, 11 Feb 2010 23:24:55 -0500 Subject: [Wtr-development] NoStatusBarException In-Reply-To: References: Message-ID: Sorry, gave the wrong path; it's in unittests/windows, not unittests/other. http://github.com/bret/watir/blob/master/watir/unittests/windows/js_events_test.rb On Thu, Feb 11, 2010 at 23:14, Bret Pettichord wrote: > I can't find that test. Could you post a link to the file in github? > > Bret > > On Thu, Feb 11, 2010 at 2:12 PM, Ethan wrote: >> >> In unittests/other/js_events_test.rb, NoStatusBarException is expected >> to be raised when calling #status on a browser window with no visible >> status bar. Is this currently correct? I do not see >> NoStatusBarException being raised anywhere; IE#status simply returns >> @ie.statusText. >> Should the test be updated? >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From bret at pettichord.com Thu Feb 11 23:50:11 2010 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 11 Feb 2010 22:50:11 -0600 Subject: [Wtr-development] NoStatusBarException In-Reply-To: References: Message-ID: Good catch. I've removed the test. Bret On Thu, Feb 11, 2010 at 10:24 PM, Ethan wrote: > Sorry, gave the wrong path; it's in unittests/windows, not unittests/other. > > > http://github.com/bret/watir/blob/master/watir/unittests/windows/js_events_test.rb > > > On Thu, Feb 11, 2010 at 23:14, Bret Pettichord > wrote: > > I can't find that test. Could you post a link to the file in github? > > > > Bret > > > > On Thu, Feb 11, 2010 at 2:12 PM, Ethan wrote: > >> > >> In unittests/other/js_events_test.rb, NoStatusBarException is expected > >> to be raised when calling #status on a browser window with no visible > >> status bar. Is this currently correct? I do not see > >> NoStatusBarException being raised anywhere; IE#status simply returns > >> @ie.statusText. > >> Should the test be updated? > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at 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 at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kunal.kr at gmail.com Tue Feb 16 01:28:55 2010 From: kunal.kr at gmail.com (Kunal Kumar) Date: Tue, 16 Feb 2010 11:58:55 +0530 Subject: [Wtr-development] XPath Support for Frame child elements Message-ID: <62d732b71002152228p501f0cadv61685d40967b4664@mail.gmail.com> Hello, I had posted my question regarding XPath Support in frame in this group before ( http://groups.google.com/group/watir-general/browse_thread/thread/947df24fa1b27f85/e23489b0cd281220?lnk=gst&q=xpath#e23489b0cd281220). The webapps for which I am trying to write watir test scripts contains frames and It was critical for me to have xpath support in frame ( as elements in frame have generated ids). I tried my hand in fixing frame class to solve the issue by referring to IE class. The solution which I took from IE works pretty well in frame as well if the domain of Frame and IE are same ( what I mean is that frame is loading content from the same domain ). If the frame domain is different, it simply throws up "Access Denied" error. Few things about the changes 1) Modified locate function to make this_frame as member variable. 2) Added functions html_source, tokenize_tagline, all_tag_attributes, element_by_xpath, elements_by_xpath, rexml_document_object, create_rexml_document_object, output_rexml_document, xml_escape, element_by_absolute_xpath from ie-class and modified accordingly Probably It would be good to inherit IE class by Frame since most of the functionality are same . What do you guys think? =================================================================================================== module Watir class Frame include Container include PageContainer # Find the frame denoted by how and what in the container and return its ole_object def locate how = @how what = @what frames = @container.document.frames target = nil for i in 0..(frames.length - 1) @this_frame = frames.item(i) case how when :index index = i + 1 return @this_frame if index == what when :name begin return @this_frame if what.matches(@this_frame.name) rescue # access denied? end when :id # We assume that pages contain frames or iframes, but not both. this_frame_tag = @container.document.getElementsByTagName("FRAME").item(i) return @this_frame if this_frame_tag and what.matches(this_frame_tag.invoke("id")) this_iframe_tag = @container.document.getElementsByTagName("IFRAME").item(i) return @this_frame if this_iframe_tag and what.matches(this_iframe_tag.invoke("id")) when :src this_frame_tag = @container.document.getElementsByTagName("FRAME").item(i) return @this_frame if this_frame_tag and what.matches(this_frame_tag.src) this_iframe_tag = @container.document.getElementsByTagName("IFRAME").item(i) return @this_frame if this_iframe_tag and what.matches(this_iframe_tag.src) else raise ArgumentError, "Argument #{how} not supported" end end raise UnknownFrameException, "Unable to locate a frame with #{how.to_s} #{what}" end def initialize(container, how, what) set_container container @how = how @what = what @o = locate copy_test_config container end def document @o.document end def attach_command @container.page_container.attach_command + ".frame(#{@how.inspect}, #{@what.inspect})" end # Returns HTML Source # Traverse the DOM tree rooted at body element # and generate the HTML source. # element: Represent Current element # htmlString:HTML Source # spaces:(Used for debugging). Helps in indentation def html_source(element, htmlString, spaceString) begin tagLine = "" outerHtml = "" tagName = "" begin tagName = element.tagName.downcase tagName = EMPTY_TAG_NAME if tagName == "" # If tag is a mismatched tag. if !(tagName =~ /^(\w|_|:)(.*)$/) return htmlString end rescue #handling text nodes htmlString += xml_escape(element.toString) return htmlString end #puts tagName #Skip comment and script tag if tagName =~ /^!/ || tagName== "script" || tagName =="style" return htmlString end #tagLine += spaceString outerHtml = all_tag_attributes(element.outerHtml) if tagName != EMPTY_TAG_NAME tagLine += "<#{tagName} #{outerHtml}" canHaveChildren = element.canHaveChildren if canHaveChildren tagLine += ">" else tagLine += "/>" #self closing tag end #spaceString += spaceString htmlString += tagLine childElements = element.childnodes childElements.each do |child| htmlString = html_source(child,htmlString,spaceString) end if canHaveChildren #tagLine += spaceString tagLine ="" htmlString += tagLine end return htmlString rescue => e puts e.to_s end return htmlString end private :html_source #Function Tokenizes the tag line and returns array of tokens. #Token could be either tagName or "=" or attribute name or attribute value #Attribute value could be either quoted string or single word def tokenize_tagline(outerHtml) outerHtml = outerHtml.gsub(/\n|\r/," ") #removing "< symbol", opening of current tag outerHtml =~ /^\s*<(.*)$/ outerHtml = $1 tokens = Array.new i = startOffset = 0 length = outerHtml.length #puts outerHtml parsingValue = false while i < length do i +=1 while (i < length && outerHtml[i,1] =~ /\s/) next if i == length currentToken = outerHtml[i,1] #Either current tag has been closed or user has not closed the tag > # and we have received the opening of next element break if currentToken =~ /<|>/ #parse quoted value if(currentToken == "\"" || currentToken == "'") parsingValue = false quote = currentToken startOffset = i i += 1 i += 1 while (i < length && (outerHtml[i,1] != quote || outerHtml[i-1,1] == "\\")) if i == length tokens.push quote + outerHtml[startOffset..i-1] else tokens.push outerHtml[startOffset..i] end elsif currentToken == "=" tokens.push "=" parsingValue = true else startOffset = i i += 1 while (i < length && !(outerHtml[i,1] =~ /\s|=|<|>/)) if !parsingValue i += 1 while (i < length && !(outerHtml[i,1] =~ /\s|<|>/)) if parsingValue parsingValue = false i -= 1 tokens.push outerHtml[startOffset..i] end i += 1 end return tokens end private :tokenize_tagline # This function get and clean all the attributes of the tag. def all_tag_attributes(outerHtml) tokens = tokenize_tagline(outerHtml) #puts tokens tagLine = "" count = 1 tokensLength = tokens.length expectedEqualityOP= false while count < tokensLength do if expectedEqualityOP == false #print Attribute Name # If attribute name is valid. Refer: http://www.w3.org/TR/REC-xml/#NT-Name if tokens[count] =~ /^(\w|_|:)(.*)$/ tagLine += " #{tokens[count]}" expectedEqualityOP = true end elsif tokens[count] == "=" count += 1 if count == tokensLength tagLine += "=\"\"" elsif(tokens[count][0,1] == "\"" || tokens[count][0,1] == "'") tagLine += "=#{tokens[count]}" else tagLine += "=\"#{tokens[count]}\"" end expectedEqualityOP = false else #Opps! equality was expected but its not there. #Set value same as the attribute name e.g. selected="selected" tagLine += "=\"#{tokens[count-1]}\"" expectedEqualityOP = false next end count += 1 end tagLine += "=\"#{tokens[count-1]}\" " if expectedEqualityOP == true #puts tagLine return tagLine end private :all_tag_attributes # return the first element that matches the xpath def element_by_xpath(xpath) temp = elements_by_xpath(xpath) temp = temp[0] if temp return temp end # execute xpath and return an array of elements def elements_by_xpath(xpath) doc = rexml_document_object modifiedXpath = "" selectedElements = Array.new doc.elements.each(xpath) do |element| modifiedXpath = element.xpath # element = a REXML element # puts "modified xpath: #{modifiedXpath}" # puts "text: #{element.text}" # puts "class: #{element.attributes['class']}" # require 'breakpoint'; breakpoint temp = element_by_absolute_xpath(modifiedXpath) # temp = a DOM/COM element selectedElements << temp if temp != nil end #puts selectedElements.length if selectedElements.length == 0 return nil else return selectedElements end end # Get the Rexml object. def rexml_document_object #puts "Value of rexmlDomobject is : #{@rexmlDomobject}" if @rexmlDomobject == nil create_rexml_document_object end return @rexmlDomobject end # Create the Rexml object if it is nil. This method is private so can be called only # from rexml_document_object method. def create_rexml_document_object # Use our modified rexml libraries require 'rexml/document' unless REXML::Version >= '3.1.4' raise "Requires REXML version of at least 3.1.4. Actual: #{REXML::Version}" end if @rexmlDomobject == nil htmlSource ="\n\n" htmlSource = html_source(@this_frame.document.body,htmlSource," ") htmlSource += "\n\n" # Angrez: Resolving Jira issue WTR-114 htmlSource = htmlSource.gsub(/ /, ' ') begin @rexmlDomobject = REXML::Document.new(htmlSource) rescue => e output_rexml_document("error.xml", htmlSource) raise e end end end private :create_rexml_document_object def output_rexml_document(name, text) file = File.open(name,"w") file.print(text) file.close end private :output_rexml_document # This function is used to escape the characters that are not valid XML data. def xml_escape(str) str = str.gsub(/&/,'&') str = str.gsub(//,'>') str = str.gsub(/"/, '"') str end private :xml_escape # Method that iterates over IE DOM object and get the elements for the given # xpath. def element_by_absolute_xpath(xpath) curElem = nil #puts "Hello; Given xpath is : #{xpath}" doc = document curElem = doc.getElementsByTagName("body")["0"] xpath =~ /^.*\/body\[?\d*\]?\/(.*)/ xpath = $1 if xpath == nil puts "Function Requires absolute XPath." return end arr = xpath.split(/\//) return nil if arr.length == 0 lastTagName = arr[arr.length-1].to_s.upcase # lastTagName is like tagName[number] or just tagName. For the first case we need to # separate tagName and number. lastTagName =~ /(\w*)\[?\d*\]?/ lastTagName = $1 #puts lastTagName for element in arr do element =~ /(\w*)\[?(\d*)\]?/ tagname = $1 tagname = tagname.upcase if $2 != nil && $2 != "" index = $2 index = "#{index}".to_i - 1 else index = 0 end #puts "#{element} #{tagname} #{index}" allElemns = curElem.childnodes if allElemns == nil || allElemns.length == 0 puts "#{element} is null" next # Go to next element end #puts "Current element is : #{curElem.tagName}" allElemns.each do |child| gotIt = false begin curTag = child.tagName curTag = EMPTY_TAG_NAME if curTag == "" rescue next end #puts child.tagName if curTag == tagname index-=1 if index < 0 curElem = child break end end end #puts "Node selected at index #{index.to_s} : #{curElem.tagName}" end begin if curElem.tagName == lastTagName #puts curElem.tagName return curElem else return nil end rescue return nil end end private :element_by_absolute_xpath EMPTY_TAG_NAME = "DUMMY" end end =================================================================================================== Thanks! Kunal ------------------------------------------------ Kunal Kumar Email: kunal.kr at gmail.com Blog: http://www.kspace.in/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Tue Feb 16 04:46:49 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 16 Feb 2010 10:46:49 +0100 Subject: [Wtr-development] XPath Support for Frame child elements In-Reply-To: <62d732b71002152228p501f0cadv61685d40967b4664@mail.gmail.com> References: <62d732b71002152228p501f0cadv61685d40967b4664@mail.gmail.com> Message-ID: On Tue, Feb 16, 2010 at 7:28 AM, Kunal Kumar wrote: > I tried my hand in fixing frame class to solve the issue by referring to IE class. Would you submit pull request? http://github.com/bret/watir Let me know if you need help with that. I have a blog post how to do it on a Mac: http://zeljkofilipin.com/2009/03/28/git-and-github-on-mac/ ?eljko -- watir.com - community manager pledgie.com/campaigns/2982 - donate to Watir watirpodcast.com - host testingpodcast.com - podcasts on software testing. all of them -------------- next part -------------- An HTML attachment was scrubbed... URL: From kunal.kr at gmail.com Tue Feb 16 08:09:08 2010 From: kunal.kr at gmail.com (Kunal Kumar) Date: Tue, 16 Feb 2010 18:39:08 +0530 Subject: [Wtr-development] XPath Support for Frame child elements In-Reply-To: <62d732b71002152228p501f0cadv61685d40967b4664@mail.gmail.com> References: <62d732b71002152228p501f0cadv61685d40967b4664@mail.gmail.com> Message-ID: <62d732b71002160509l47187cc2ib9cccba7cb7b5e1c@mail.gmail.com> >On Tue, Feb 16, 2010 at 7:28 AM, Kunal Kumar wrote: >> I tried my hand in fixing frame class to solve the issue by referring to IE class. >Would you submit pull request? >http://github.com/bret/watir Sure! Don't you think Frame should inherit from IE class ? Thanks! Kunal --------------- Blog: http://www.kspace.in/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Tue Feb 16 14:00:39 2010 From: bret at pettichord.com (Bret Pettichord) Date: Tue, 16 Feb 2010 13:00:39 -0600 Subject: [Wtr-development] XPath Support for Frame child elements In-Reply-To: <62d732b71002152228p501f0cadv61685d40967b4664@mail.gmail.com> References: <62d732b71002152228p501f0cadv61685d40967b4664@mail.gmail.com> Message-ID: Thanks for sharing this. On Tue, Feb 16, 2010 at 12:28 AM, Kunal Kumar wrote: > Hello, > > I had posted my question regarding XPath Support in frame in this group > before > ( > http://groups.google.com/group/watir-general/browse_thread/thread/947df24fa1b27f85/e23489b0cd281220?lnk=gst&q=xpath#e23489b0cd281220). > > > The webapps for which I am trying to write watir test scripts contains > frames and It was critical for me to have xpath support in frame ( as > elements in frame have generated ids). > > I tried my hand in fixing frame class to solve the issue by referring to IE > class. The solution which I took from IE works pretty well in frame as well > if the domain of Frame and IE are same ( what I mean is that frame is > loading content from the same domain ). If the frame domain is different, it > simply throws up "Access Denied" error. > > Few things about the changes > > 1) Modified locate function to make this_frame as member variable. > I'm confused about this. I don't see any references to it in your code outside of the method that defines it. > 2) Added functions html_source, tokenize_tagline, all_tag_attributes, > element_by_xpath, elements_by_xpath, rexml_document_object, > create_rexml_document_object, output_rexml_document, xml_escape, > element_by_absolute_xpath from ie-class and modified accordingly > > Probably It would be good to inherit IE class by Frame since most of the > functionality are same . What do you guys think? > The PageContainer module was created as a place to store functionality that was common to both IE and Frame. In general, I read your code as a monkey patch, rather than as code changes. Is this your intention? Bret -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From kunal.kr at gmail.com Tue Feb 16 14:11:20 2010 From: kunal.kr at gmail.com (Kunal Kumar) Date: Wed, 17 Feb 2010 00:41:20 +0530 Subject: [Wtr-development] XPath Support for Frame child elements In-Reply-To: References: <62d732b71002152228p501f0cadv61685d40967b4664@mail.gmail.com> Message-ID: <62d732b71002161111r5311cceek78276bdde42e4e7e@mail.gmail.com> On Wed, Feb 17, 2010 at 12:30 AM, Bret Pettichord wrote: > Thanks for sharing this. > > 1) Modified locate function to make this_frame as member variable. >> > > I'm confused about this. I don't see any references to it in your code > outside of the method that defines it. > There is! this_frame is being used in function create_rexml_document_object > > >> 2) Added functions html_source, tokenize_tagline, all_tag_attributes, >> element_by_xpath, elements_by_xpath, rexml_document_object, >> create_rexml_document_object, output_rexml_document, xml_escape, >> element_by_absolute_xpath from ie-class and modified accordingly >> >> Probably It would be good to inherit IE class by Frame since most of the >> functionality are same . What do you guys think? >> > > The PageContainer module was created as a place to store functionality that > was common to both IE and Frame. > > In general, I read your code as a monkey patch, rather than as code > changes. Is this your intention? > Nope. Definitely not! This is definitely not the ideal way. I was thinking of making frame class as derived class of IE class. ( I discarded that idea too.) I'll have a look at PageContainer module and see if that can be organized in better way. BTW, your thoughts on how should we do the changes? > > Bret > > -- > 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > ------------------------------------------------ Kunal Kumar Email: kunal.kr at gmail.com Blog: http://www.kspace.in/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Tue Feb 16 16:13:27 2010 From: notethan at gmail.com (Ethan) Date: Tue, 16 Feb 2010 16:13:27 -0500 Subject: [Wtr-development] @ie.readyState Message-ID: Watir::IE#wait checks that @ie.readyState == READYSTATE_COMPLETE, where READYSTATE_COMPLETE is 4. I'm running into issues where, after completing a file download, @ie.readyState is 3. The relevant documentation for this property seems to be at http://msdn.microsoft.com/en-us/library/ms534361%28VS.85%29.aspx (although I do not known precisely whan an "OBJECT" is in this context, it seems to apply to the @ie object). aside: that is not to be confused with the readyState property of a document, which is slightly different and is documented here: http://msdn.microsoft.com/en-us/library/ms534359%28VS.85%29.aspx the readyState of the document is "complete" in this case, despite the readyState of the browser being 3 which corresponds to "interactive". Since a readyState of 3 means "User can interact with the object even though it is not fully loaded.", should that not be a valid state for Watir to consider the browser to be ready? I'm not sure why that description applies to the browser after a file download completes - maybe it shouldn't? maybe it's an IE bug? But, it does seem to me that that description describes a state where it should be ready for Watir to interact with it, so perhaps that check should be changed to @ie.readyState >= 3. Likewise, maybe the checks for the document's readyState (and that of all its frames) should be changed to check if it is either "complete" or "interactive"? Although I have not seen the 'interactive' state come up in my own experience. -Ethan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeroen at vanmenen.nl Tue Feb 16 16:22:41 2010 From: jeroen at vanmenen.nl (Jeroen van Menen) Date: Tue, 16 Feb 2010 22:22:41 +0100 Subject: [Wtr-development] @ie.readyState In-Reply-To: References: Message-ID: <5aafe60e1002161322y75637564we30c05d4c403f0df@mail.gmail.com> Hi Ethan, In my tests, that I run with WatiN (.Net version of watir), I also check for the readyState "interactive" and haven't experienced any problems (using it with a lager test suite). But the check is not in the official code so I don't know if it would work for "everybody". Hth, Jeroen On Tue, Feb 16, 2010 at 10:13 PM, Ethan wrote: > Watir::IE#wait checks that @ie.readyState == READYSTATE_COMPLETE, where > READYSTATE_COMPLETE is 4. > > I'm running into issues where, after completing a file download, > @ie.readyState is 3. > > The relevant documentation for this property seems to be at > http://msdn.microsoft.com/en-us/library/ms534361%28VS.85%29.aspx (although > I do not known precisely whan an "OBJECT" is in this context, it seems to > apply to the @ie object). > > aside: that is not to be confused with the readyState property of a > document, which is slightly different and is documented here: > http://msdn.microsoft.com/en-us/library/ms534359%28VS.85%29.aspx > the readyState of the document is "complete" in this case, despite the > readyState of the browser being 3 which corresponds to "interactive". > > Since a readyState of 3 means "User can interact with the object even > though it is not fully loaded.", should that not be a valid state for Watir > to consider the browser to be ready? > > I'm not sure why that description applies to the browser after a file > download completes - maybe it shouldn't? maybe it's an IE bug? > But, it does seem to me that that description describes a state where it > should be ready for Watir to interact with it, so perhaps that check should > be changed to @ie.readyState >= 3. > Likewise, maybe the checks for the document's readyState (and that of all > its frames) should be changed to check if it is either "complete" or > "interactive"? Although I have not seen the 'interactive' state come up in > my own experience. > > -Ethan > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.rogers at shaw.ca Tue Feb 16 16:44:50 2010 From: paul.rogers at shaw.ca (Paul Rogers) Date: Tue, 16 Feb 2010 14:44:50 -0700 Subject: [Wtr-development] @ie.readyState In-Reply-To: <5aafe60e1002161322y75637564we30c05d4c403f0df@mail.gmail.com> References: <5aafe60e1002161322y75637564we30c05d4c403f0df@mail.gmail.com> Message-ID: I think its pretty important we get it 'right'. This is one of the big advanages of watir over other tools, in that it 'knows' when the page has loaded. Of cource, I have no idea what is right. Paul On Tue, Feb 16, 2010 at 2:22 PM, Jeroen van Menen wrote: > Hi Ethan, > > In my tests, that I run with WatiN (.Net version of watir), I also check > for the readyState "interactive" and haven't experienced any problems (using > it with a lager test suite). But the check is not in the official code so I > don't know if it would work for "everybody". > > Hth, > Jeroen > > On Tue, Feb 16, 2010 at 10:13 PM, Ethan wrote: > >> Watir::IE#wait checks that @ie.readyState == READYSTATE_COMPLETE, where >> READYSTATE_COMPLETE is 4. >> >> I'm running into issues where, after completing a file download, >> @ie.readyState is 3. >> >> The relevant documentation for this property seems to be at >> http://msdn.microsoft.com/en-us/library/ms534361%28VS.85%29.aspx(although I do not known precisely whan an "OBJECT" is in this context, it >> seems to apply to the @ie object). >> >> aside: that is not to be confused with the readyState property of a >> document, which is slightly different and is documented here: >> http://msdn.microsoft.com/en-us/library/ms534359%28VS.85%29.aspx >> the readyState of the document is "complete" in this case, despite the >> readyState of the browser being 3 which corresponds to "interactive". >> >> Since a readyState of 3 means "User can interact with the object even >> though it is not fully loaded.", should that not be a valid state for Watir >> to consider the browser to be ready? >> >> I'm not sure why that description applies to the browser after a file >> download completes - maybe it shouldn't? maybe it's an IE bug? >> But, it does seem to me that that description describes a state where it >> should be ready for Watir to interact with it, so perhaps that check should >> be changed to @ie.readyState >= 3. >> Likewise, maybe the checks for the document's readyState (and that of all >> its frames) should be changed to check if it is either "complete" or >> "interactive"? Although I have not seen the 'interactive' state come up in >> my own experience. >> >> -Ethan >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> >> > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Tue Feb 16 17:09:10 2010 From: bret at pettichord.com (Bret Pettichord) Date: Tue, 16 Feb 2010 16:09:10 -0600 Subject: [Wtr-development] @ie.readyState In-Reply-To: References: Message-ID: I am confused. Is it possible that you mixed up the two links to the Microsoft docs? The first says a readystate of 3 means the object is not available, whereas the second says that 3 means it is. Bret On Tue, Feb 16, 2010 at 3:13 PM, Ethan wrote: > Watir::IE#wait checks that @ie.readyState == READYSTATE_COMPLETE, where > READYSTATE_COMPLETE is 4. > > I'm running into issues where, after completing a file download, > @ie.readyState is 3. > > The relevant documentation for this property seems to be at > http://msdn.microsoft.com/en-us/library/ms534361%28VS.85%29.aspx (although > I do not known precisely whan an "OBJECT" is in this context, it seems to > apply to the @ie object). > > aside: that is not to be confused with the readyState property of a > document, which is slightly different and is documented here: > http://msdn.microsoft.com/en-us/library/ms534359%28VS.85%29.aspx > the readyState of the document is "complete" in this case, despite the > readyState of the browser being 3 which corresponds to "interactive". > > Since a readyState of 3 means "User can interact with the object even > though it is not fully loaded.", should that not be a valid state for Watir > to consider the browser to be ready? > > I'm not sure why that description applies to the browser after a file > download completes - maybe it shouldn't? maybe it's an IE bug? > But, it does seem to me that that description describes a state where it > should be ready for Watir to interact with it, so perhaps that check should > be changed to @ie.readyState >= 3. > Likewise, maybe the checks for the document's readyState (and that of all > its frames) should be changed to check if it is either "complete" or > "interactive"? Although I have not seen the 'interactive' state come up in > my own experience. > > -Ethan > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Tue Feb 16 17:48:05 2010 From: notethan at gmail.com (Ethan) Date: Tue, 16 Feb 2010 17:48:05 -0500 Subject: [Wtr-development] @ie.readyState In-Reply-To: References: Message-ID: Sorry, you are right, I did get the links wrong. The first link should have been http://msdn.microsoft.com/en-us/library/ms534360%28VS.85%29.aspx which applies to "OBJECT" types, whatever that means (but does include Watir's @ie object). My actual first link is to XMLHttpRequest documentation, which is not at all relevant to this discussion. The second link, for document and frame objects, was correct. -Ethan On Tue, Feb 16, 2010 at 17:09, Bret Pettichord wrote: > I am confused. Is it possible that you mixed up the two links to the > Microsoft docs? The first says a readystate of 3 means the object is not > available, whereas the second says that 3 means it is. > > Bret > > On Tue, Feb 16, 2010 at 3:13 PM, Ethan wrote: > >> Watir::IE#wait checks that @ie.readyState == READYSTATE_COMPLETE, where >> READYSTATE_COMPLETE is 4. >> >> I'm running into issues where, after completing a file download, >> @ie.readyState is 3. >> >> The relevant documentation for this property seems to be at >> http://msdn.microsoft.com/en-us/library/ms534361%28VS.85%29.aspx(although I do not known precisely whan an "OBJECT" is in this context, it >> seems to apply to the @ie object). >> >> aside: that is not to be confused with the readyState property of a >> document, which is slightly different and is documented here: >> http://msdn.microsoft.com/en-us/library/ms534359%28VS.85%29.aspx >> the readyState of the document is "complete" in this case, despite the >> readyState of the browser being 3 which corresponds to "interactive". >> >> Since a readyState of 3 means "User can interact with the object even >> though it is not fully loaded.", should that not be a valid state for Watir >> to consider the browser to be ready? >> >> I'm not sure why that description applies to the browser after a file >> download completes - maybe it shouldn't? maybe it's an IE bug? >> But, it does seem to me that that description describes a state where it >> should be ready for Watir to interact with it, so perhaps that check should >> be changed to @ie.readyState >= 3. >> Likewise, maybe the checks for the document's readyState (and that of all >> its frames) should be changed to check if it is either "complete" or >> "interactive"? Although I have not seen the 'interactive' state come up in >> my own experience. >> >> -Ethan >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.rogers at shaw.ca Tue Feb 16 17:53:43 2010 From: paul.rogers at shaw.ca (Paul Rogers) Date: Tue, 16 Feb 2010 15:53:43 -0700 Subject: [Wtr-development] @ie.readyState In-Reply-To: References: Message-ID: I think that first link is for an tag, perhaps a flash object or similar Paul On Tue, Feb 16, 2010 at 3:48 PM, Ethan wrote: > Sorry, you are right, I did get the links wrong. The first link should have > been > http://msdn.microsoft.com/en-us/library/ms534360%28VS.85%29.aspx > which applies to "OBJECT" types, whatever that means (but does include > Watir's @ie object). > My actual first link is to XMLHttpRequest documentation, which is not at > all relevant to this discussion. > > The second link, for document and frame objects, was correct. > > -Ethan > > > On Tue, Feb 16, 2010 at 17:09, Bret Pettichord wrote: > >> I am confused. Is it possible that you mixed up the two links to the >> Microsoft docs? The first says a readystate of 3 means the object is not >> available, whereas the second says that 3 means it is. >> >> Bret >> >> On Tue, Feb 16, 2010 at 3:13 PM, Ethan wrote: >> >>> Watir::IE#wait checks that @ie.readyState == READYSTATE_COMPLETE, where >>> READYSTATE_COMPLETE is 4. >>> >>> I'm running into issues where, after completing a file download, >>> @ie.readyState is 3. >>> >>> The relevant documentation for this property seems to be at >>> http://msdn.microsoft.com/en-us/library/ms534361%28VS.85%29.aspx(although I do not known precisely whan an "OBJECT" is in this context, it >>> seems to apply to the @ie object). >>> >>> aside: that is not to be confused with the readyState property of a >>> document, which is slightly different and is documented here: >>> http://msdn.microsoft.com/en-us/library/ms534359%28VS.85%29.aspx >>> the readyState of the document is "complete" in this case, despite the >>> readyState of the browser being 3 which corresponds to "interactive". >>> >>> Since a readyState of 3 means "User can interact with the object even >>> though it is not fully loaded.", should that not be a valid state for Watir >>> to consider the browser to be ready? >>> >>> I'm not sure why that description applies to the browser after a file >>> download completes - maybe it shouldn't? maybe it's an IE bug? >>> But, it does seem to me that that description describes a state where it >>> should be ready for Watir to interact with it, so perhaps that check should >>> be changed to @ie.readyState >= 3. >>> Likewise, maybe the checks for the document's readyState (and that of all >>> its frames) should be changed to check if it is either "complete" or >>> "interactive"? Although I have not seen the 'interactive' state come up in >>> my own experience. >>> >>> -Ethan >>> >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Tue Feb 16 17:57:38 2010 From: notethan at gmail.com (Ethan) Date: Tue, 16 Feb 2010 17:57:38 -0500 Subject: [Wtr-development] @ie.readyState In-Reply-To: References: Message-ID: That does make sense. Does it seem like the same documentation applies to the @ie object as well though? It is rather different than an element, but it seems like the numbers and descriptions correspond well enough. On Tue, Feb 16, 2010 at 17:53, Paul Rogers wrote: > I think that first link is for an tag, perhaps a flash object or > similar > > Paul > > > On Tue, Feb 16, 2010 at 3:48 PM, Ethan wrote: > >> Sorry, you are right, I did get the links wrong. The first link should >> have been >> http://msdn.microsoft.com/en-us/library/ms534360%28VS.85%29.aspx >> which applies to "OBJECT" types, whatever that means (but does include >> Watir's @ie object). >> My actual first link is to XMLHttpRequest documentation, which is not at >> all relevant to this discussion. >> >> The second link, for document and frame objects, was correct. >> >> -Ethan >> >> >> On Tue, Feb 16, 2010 at 17:09, Bret Pettichord wrote: >> >>> I am confused. Is it possible that you mixed up the two links to the >>> Microsoft docs? The first says a readystate of 3 means the object is not >>> available, whereas the second says that 3 means it is. >>> >>> Bret >>> >>> On Tue, Feb 16, 2010 at 3:13 PM, Ethan wrote: >>> >>>> Watir::IE#wait checks that @ie.readyState == READYSTATE_COMPLETE, where >>>> READYSTATE_COMPLETE is 4. >>>> >>>> I'm running into issues where, after completing a file download, >>>> @ie.readyState is 3. >>>> >>>> The relevant documentation for this property seems to be at >>>> http://msdn.microsoft.com/en-us/library/ms534361%28VS.85%29.aspx(although I do not known precisely whan an "OBJECT" is in this context, it >>>> seems to apply to the @ie object). >>>> >>>> aside: that is not to be confused with the readyState property of a >>>> document, which is slightly different and is documented here: >>>> http://msdn.microsoft.com/en-us/library/ms534359%28VS.85%29.aspx >>>> the readyState of the document is "complete" in this case, despite the >>>> readyState of the browser being 3 which corresponds to "interactive". >>>> >>>> Since a readyState of 3 means "User can interact with the object even >>>> though it is not fully loaded.", should that not be a valid state for Watir >>>> to consider the browser to be ready? >>>> >>>> I'm not sure why that description applies to the browser after a file >>>> download completes - maybe it shouldn't? maybe it's an IE bug? >>>> But, it does seem to me that that description describes a state where it >>>> should be ready for Watir to interact with it, so perhaps that check should >>>> be changed to @ie.readyState >= 3. >>>> Likewise, maybe the checks for the document's readyState (and that of >>>> all its frames) should be changed to check if it is either "complete" or >>>> "interactive"? Although I have not seen the 'interactive' state come up in >>>> my own experience. >>>> >>>> -Ethan >>>> >>>> >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development at 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 at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.rogers at shaw.ca Tue Feb 16 18:03:42 2010 From: paul.rogers at shaw.ca (Paul Rogers) Date: Tue, 16 Feb 2010 16:03:42 -0700 Subject: [Wtr-development] @ie.readyState In-Reply-To: References: Message-ID: if I remember, there is a document.onReadyState changed and also one that applies to the browser itself. Paul On Tue, Feb 16, 2010 at 3:57 PM, Ethan wrote: > That does make sense. Does it seem like the same documentation applies to > the @ie object as well though? It is rather different than an > element, but it seems like the numbers and descriptions correspond well > enough. > > On Tue, Feb 16, 2010 at 17:53, Paul Rogers wrote: > >> I think that first link is for an tag, perhaps a flash object or >> similar >> >> Paul >> >> >> On Tue, Feb 16, 2010 at 3:48 PM, Ethan wrote: >> >>> Sorry, you are right, I did get the links wrong. The first link should >>> have been >>> http://msdn.microsoft.com/en-us/library/ms534360%28VS.85%29.aspx >>> which applies to "OBJECT" types, whatever that means (but does include >>> Watir's @ie object). >>> My actual first link is to XMLHttpRequest documentation, which is not at >>> all relevant to this discussion. >>> >>> The second link, for document and frame objects, was correct. >>> >>> -Ethan >>> >>> >>> On Tue, Feb 16, 2010 at 17:09, Bret Pettichord wrote: >>> >>>> I am confused. Is it possible that you mixed up the two links to the >>>> Microsoft docs? The first says a readystate of 3 means the object is not >>>> available, whereas the second says that 3 means it is. >>>> >>>> Bret >>>> >>>> On Tue, Feb 16, 2010 at 3:13 PM, Ethan wrote: >>>> >>>>> Watir::IE#wait checks that @ie.readyState == READYSTATE_COMPLETE, >>>>> where READYSTATE_COMPLETE is 4. >>>>> >>>>> I'm running into issues where, after completing a file download, >>>>> @ie.readyState is 3. >>>>> >>>>> The relevant documentation for this property seems to be at >>>>> http://msdn.microsoft.com/en-us/library/ms534361%28VS.85%29.aspx(although I do not known precisely whan an "OBJECT" is in this context, it >>>>> seems to apply to the @ie object). >>>>> >>>>> aside: that is not to be confused with the readyState property of a >>>>> document, which is slightly different and is documented here: >>>>> http://msdn.microsoft.com/en-us/library/ms534359%28VS.85%29.aspx >>>>> the readyState of the document is "complete" in this case, despite the >>>>> readyState of the browser being 3 which corresponds to "interactive". >>>>> >>>>> Since a readyState of 3 means "User can interact with the object even >>>>> though it is not fully loaded.", should that not be a valid state for Watir >>>>> to consider the browser to be ready? >>>>> >>>>> I'm not sure why that description applies to the browser after a file >>>>> download completes - maybe it shouldn't? maybe it's an IE bug? >>>>> But, it does seem to me that that description describes a state where >>>>> it should be ready for Watir to interact with it, so perhaps that check >>>>> should be changed to @ie.readyState >= 3. >>>>> Likewise, maybe the checks for the document's readyState (and that of >>>>> all its frames) should be changed to check if it is either "complete" or >>>>> "interactive"? Although I have not seen the 'interactive' state come up in >>>>> my own experience. >>>>> >>>>> -Ethan >>>>> >>>>> >>>>> _______________________________________________ >>>>> Wtr-development mailing list >>>>> Wtr-development at 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 at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>> >>> >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Tue Feb 16 18:02:54 2010 From: bret at pettichord.com (Bret Pettichord) Date: Tue, 16 Feb 2010 17:02:54 -0600 Subject: [Wtr-development] @ie.readyState In-Reply-To: References: Message-ID: I think this is the correct documentation. http://msdn.microsoft.com/en-us/library/system.windows.forms.webbrowserreadystate.aspx It does imply that ReadyState == 3 might be fine. I suggest we make this user-configurable in Watir, so that we get more people to give it a shot, before we change the default behavior. Bret On Tue, Feb 16, 2010 at 4:57 PM, Ethan wrote: > That does make sense. Does it seem like the same documentation applies to > the @ie object as well though? It is rather different than an > element, but it seems like the numbers and descriptions correspond well > enough. > > On Tue, Feb 16, 2010 at 17:53, Paul Rogers wrote: > >> I think that first link is for an tag, perhaps a flash object or >> similar >> >> Paul >> >> >> On Tue, Feb 16, 2010 at 3:48 PM, Ethan wrote: >> >>> Sorry, you are right, I did get the links wrong. The first link should >>> have been >>> http://msdn.microsoft.com/en-us/library/ms534360%28VS.85%29.aspx >>> which applies to "OBJECT" types, whatever that means (but does include >>> Watir's @ie object). >>> My actual first link is to XMLHttpRequest documentation, which is not at >>> all relevant to this discussion. >>> >>> The second link, for document and frame objects, was correct. >>> >>> -Ethan >>> >>> >>> On Tue, Feb 16, 2010 at 17:09, Bret Pettichord wrote: >>> >>>> I am confused. Is it possible that you mixed up the two links to the >>>> Microsoft docs? The first says a readystate of 3 means the object is not >>>> available, whereas the second says that 3 means it is. >>>> >>>> Bret >>>> >>>> On Tue, Feb 16, 2010 at 3:13 PM, Ethan wrote: >>>> >>>>> Watir::IE#wait checks that @ie.readyState == READYSTATE_COMPLETE, >>>>> where READYSTATE_COMPLETE is 4. >>>>> >>>>> I'm running into issues where, after completing a file download, >>>>> @ie.readyState is 3. >>>>> >>>>> The relevant documentation for this property seems to be at >>>>> http://msdn.microsoft.com/en-us/library/ms534361%28VS.85%29.aspx(although I do not known precisely whan an "OBJECT" is in this context, it >>>>> seems to apply to the @ie object). >>>>> >>>>> aside: that is not to be confused with the readyState property of a >>>>> document, which is slightly different and is documented here: >>>>> http://msdn.microsoft.com/en-us/library/ms534359%28VS.85%29.aspx >>>>> the readyState of the document is "complete" in this case, despite the >>>>> readyState of the browser being 3 which corresponds to "interactive". >>>>> >>>>> Since a readyState of 3 means "User can interact with the object even >>>>> though it is not fully loaded.", should that not be a valid state for Watir >>>>> to consider the browser to be ready? >>>>> >>>>> I'm not sure why that description applies to the browser after a file >>>>> download completes - maybe it shouldn't? maybe it's an IE bug? >>>>> But, it does seem to me that that description describes a state where >>>>> it should be ready for Watir to interact with it, so perhaps that check >>>>> should be changed to @ie.readyState >= 3. >>>>> Likewise, maybe the checks for the document's readyState (and that of >>>>> all its frames) should be changed to check if it is either "complete" or >>>>> "interactive"? Although I have not seen the 'interactive' state come up in >>>>> my own experience. >>>>> >>>>> -Ethan >>>>> >>>>> >>>>> _______________________________________________ >>>>> Wtr-development mailing list >>>>> Wtr-development at 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 at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>> >>> >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Tue Feb 16 20:13:30 2010 From: notethan at gmail.com (Ethan) Date: Tue, 16 Feb 2010 20:13:30 -0500 Subject: [Wtr-development] @ie.readyState In-Reply-To: References: Message-ID: Ah, that's the one, I couldn't seem to find that. Thanks. I have tentatively changed #wait to allow the WebBrowserReadyState.Interactive state (3) in my application and am currently running tests against it. On Tue, Feb 16, 2010 at 18:02, Bret Pettichord wrote: > I think this is the correct documentation. > > http://msdn.microsoft.com/en-us/library/system.windows.forms.webbrowserreadystate.aspx > > It does imply that ReadyState == 3 might be fine. > > I suggest we make this user-configurable in Watir, so that we get more > people to give it a shot, before we change the default behavior. > > Bret > > > On Tue, Feb 16, 2010 at 4:57 PM, Ethan wrote: > >> That does make sense. Does it seem like the same documentation applies to >> the @ie object as well though? It is rather different than an >> element, but it seems like the numbers and descriptions correspond well >> enough. >> >> On Tue, Feb 16, 2010 at 17:53, Paul Rogers wrote: >> >>> I think that first link is for an tag, perhaps a flash object or >>> similar >>> >>> Paul >>> >>> >>> On Tue, Feb 16, 2010 at 3:48 PM, Ethan wrote: >>> >>>> Sorry, you are right, I did get the links wrong. The first link should >>>> have been >>>> http://msdn.microsoft.com/en-us/library/ms534360%28VS.85%29.aspx >>>> which applies to "OBJECT" types, whatever that means (but does include >>>> Watir's @ie object). >>>> My actual first link is to XMLHttpRequest documentation, which is not at >>>> all relevant to this discussion. >>>> >>>> The second link, for document and frame objects, was correct. >>>> >>>> -Ethan >>>> >>>> >>>> On Tue, Feb 16, 2010 at 17:09, Bret Pettichord wrote: >>>> >>>>> I am confused. Is it possible that you mixed up the two links to the >>>>> Microsoft docs? The first says a readystate of 3 means the object is not >>>>> available, whereas the second says that 3 means it is. >>>>> >>>>> Bret >>>>> >>>>> On Tue, Feb 16, 2010 at 3:13 PM, Ethan wrote: >>>>> >>>>>> Watir::IE#wait checks that @ie.readyState == READYSTATE_COMPLETE, >>>>>> where READYSTATE_COMPLETE is 4. >>>>>> >>>>>> I'm running into issues where, after completing a file download, >>>>>> @ie.readyState is 3. >>>>>> >>>>>> The relevant documentation for this property seems to be at >>>>>> http://msdn.microsoft.com/en-us/library/ms534361%28VS.85%29.aspx(although I do not known precisely whan an "OBJECT" is in this context, it >>>>>> seems to apply to the @ie object). >>>>>> >>>>>> aside: that is not to be confused with the readyState property of a >>>>>> document, which is slightly different and is documented here: >>>>>> http://msdn.microsoft.com/en-us/library/ms534359%28VS.85%29.aspx >>>>>> the readyState of the document is "complete" in this case, despite the >>>>>> readyState of the browser being 3 which corresponds to "interactive". >>>>>> >>>>>> Since a readyState of 3 means "User can interact with the object even >>>>>> though it is not fully loaded.", should that not be a valid state for Watir >>>>>> to consider the browser to be ready? >>>>>> >>>>>> I'm not sure why that description applies to the browser after a file >>>>>> download completes - maybe it shouldn't? maybe it's an IE bug? >>>>>> But, it does seem to me that that description describes a state where >>>>>> it should be ready for Watir to interact with it, so perhaps that check >>>>>> should be changed to @ie.readyState >= 3. >>>>>> Likewise, maybe the checks for the document's readyState (and that of >>>>>> all its frames) should be changed to check if it is either "complete" or >>>>>> "interactive"? Although I have not seen the 'interactive' state come up in >>>>>> my own experience. >>>>>> >>>>>> -Ethan >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Wtr-development mailing list >>>>>> Wtr-development at 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 at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>> >>> >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Wed Feb 17 03:20:51 2010 From: jarmo.p at gmail.com (Jarmo) Date: Wed, 17 Feb 2010 10:20:51 +0200 Subject: [Wtr-development] @ie.readyState Message-ID: Is it really needed to have it possible to configure (e.g. writing new code which is not needed in the future)? Just create one monkey-patch what would be possible to require in if wanted and that's it. Or might there be any problems with that temporary solution? Jarmo > I think this is the correct documentation. > http://msdn.microsoft.com/en-us/library/system.windows.forms.webbrowserreadystate.aspx > It does imply that ReadyState == 3 might be fine. > I suggest we make this user-configurable in Watir, so that we get more > people to give it a shot, before we change the default behavior. > Bret From bret at pettichord.com Wed Feb 17 11:03:24 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 17 Feb 2010 10:03:24 -0600 Subject: [Wtr-development] @ie.readyState In-Reply-To: References: Message-ID: I agree with the sentiment. One of the troubles is that there are lots of conflicting monkey patches out there for the wait method. So it really should be refactored into a composed method to make it easier to combine modifications. Bret On Wed, Feb 17, 2010 at 2:20 AM, Jarmo wrote: > Is it really needed to have it possible to configure (e.g. writing new > code which is not needed in the future)? Just create one monkey-patch > what would be possible to require in if wanted and that's it. Or might > there be any problems with that temporary solution? > > Jarmo > > > I think this is the correct documentation. > > > http://msdn.microsoft.com/en-us/library/system.windows.forms.webbrowserreadystate.aspx > > > It does imply that ReadyState == 3 might be fine. > > > I suggest we make this user-configurable in Watir, so that we get more > > people to give it a shot, before we change the default behavior. > > > Bret > _______________________________________________ > Wtr-development mailing list > Wtr-development at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Wed Feb 17 11:07:26 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 17 Feb 2010 10:07:26 -0600 Subject: [Wtr-development] XPath Support for Frame child elements In-Reply-To: <62d732b71002161111r5311cceek78276bdde42e4e7e@mail.gmail.com> References: <62d732b71002152228p501f0cadv61685d40967b4664@mail.gmail.com> <62d732b71002161111r5311cceek78276bdde42e4e7e@mail.gmail.com> Message-ID: On Tue, Feb 16, 2010 at 1:11 PM, Kunal Kumar wrote: > > BTW, your thoughts on how should we do the changes? > The best way would be to fork the code on github, make your changes, add unit tests, and then make a pull request. Bret -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Mon Feb 22 06:45:50 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 22 Feb 2010 12:45:50 +0100 Subject: [Wtr-development] Resolved tickets in Jira Message-ID: If you have ever opened a Watir Jira ticket, please take a look at the list of resolved tickets: http://bit.ly/bWrLY3 If the ticket you have opened is resolved, please check if it is really fixed, and then close of reopen it. Some tickets are resolved in 2006 but never closed. I will try to contact all reporters individually. If a ticket is not reopened or closed in a few weeks I will close it myself. ?eljko -- watir.com - community manager pledgie.com/campaigns/2982 - donate to Watir watirpodcast.com - host testingpodcast.com - podcasts on software testing. all of them -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Mon Feb 22 07:17:27 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Mon, 22 Feb 2010 13:17:27 +0100 Subject: [Wtr-development] Resolved tickets in Jira In-Reply-To: References: Message-ID: On Sun, Nov 15, 2009 at 10:35 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > When I get some time I will contact the reporters and ask them to close the tickets. I have started notifying reporters that their tickets are resolved. I hope I will notify everybody this week. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From abaird at bairdsnet.net Mon Feb 22 19:09:38 2010 From: abaird at bairdsnet.net (Alan Baird) Date: Mon, 22 Feb 2010 18:09:38 -0600 Subject: [Wtr-development] Resolved tickets in Jira In-Reply-To: References: Message-ID: <2a379a301002221609l7c419881ic664b1ee162dcb98@mail.gmail.com> I tried to mark some of my tickets as closed. I don't know if I need permissions do do this or not but I couldn't find any option to close the ticket. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Mon Feb 22 19:32:31 2010 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 22 Feb 2010 18:32:31 -0600 Subject: [Wtr-development] Resolved tickets in Jira In-Reply-To: <2a379a301002221609l7c419881ic664b1ee162dcb98@mail.gmail.com> References: <2a379a301002221609l7c419881ic664b1ee162dcb98@mail.gmail.com> Message-ID: You might need to be added to the watir-committers list on openqa. (Which no longer has anything to do with commit rights.) On Feb 22, 2010 6:13 PM, "Alan Baird" wrote: I tried to mark some of my tickets as closed. I don't know if I need permissions do do this or not but I couldn't find any option to close the ticket. Alan _______________________________________________ Wtr-development mailing list Wtr-development at rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-development -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Tue Feb 23 00:53:50 2010 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 22 Feb 2010 23:53:50 -0600 Subject: [Wtr-development] Install Doc Updates Message-ID: Hey, I just took a look at Watir.com, not sure why, and noticed that we have a bunch of comments on our install page. http://watir.com/installation/ It looks like Alister updated the page based on some of the earlier suggestions, but some later ones have yet to be acted on. Most seem pretty reasonable. Wondering if some one would like to volunteer to do this? Some one besides Alister or Zeljko? Bret -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From angrez at gmail.com Tue Feb 23 02:14:51 2010 From: angrez at gmail.com (Angrez Singh) Date: Tue, 23 Feb 2010 12:44:51 +0530 Subject: [Wtr-development] Install Doc Updates In-Reply-To: References: Message-ID: I can edit the page, can someone let me know how to do that? On Tue, Feb 23, 2010 at 11:23 AM, Bret Pettichord wrote: > Hey, > > I just took a look at Watir.com, not sure why, and noticed that we have a > bunch of comments on our install page. > http://watir.com/installation/ > > It looks like Alister updated the page based on some of the earlier > suggestions, but some later ones have yet to be acted on. Most seem pretty > reasonable. Wondering if some one would like to volunteer to do this? Some > one besides Alister or Zeljko? > > Bret > > -- > 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angrez at gmail.com Tue Feb 23 02:09:41 2010 From: angrez at gmail.com (Angrez Singh) Date: Tue, 23 Feb 2010 12:39:41 +0530 Subject: [Wtr-development] Resolved tickets in Jira In-Reply-To: References: <2a379a301002221609l7c419881ic664b1ee162dcb98@mail.gmail.com> Message-ID: I resolved most of the tickets that were moved from Google code to JIRA. Will go through them once again to see if anything is duplicate or can be resolved/closed. - Angrez On Tue, Feb 23, 2010 at 6:02 AM, Bret Pettichord wrote: > You might need to be added to the watir-committers list on openqa. (Which > no longer has anything to do with commit rights.) > > On Feb 22, 2010 6:13 PM, "Alan Baird" wrote: > > I tried to mark some of my tickets as closed. I don't know if I need > permissions do do this or not but I couldn't find any option to close the > ticket. > > Alan > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Tue Feb 23 05:18:35 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 23 Feb 2010 11:18:35 +0100 Subject: [Wtr-development] Install Doc Updates In-Reply-To: References: Message-ID: On Tue, Feb 23, 2010 at 8:14 AM, Angrez Singh wrote: > I can edit the page, can someone let me know how to do that? Angrez, I have invited you to the blog. Please create an account (you should receive e-mail from wordpress.com) so I can add you to watir.com blog. Please let me know when you create the account, I am not sure if Wordpress will let me know. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From angrez at gmail.com Tue Feb 23 06:47:02 2010 From: angrez at gmail.com (Angrez Singh) Date: Tue, 23 Feb 2010 17:17:02 +0530 Subject: [Wtr-development] Install Doc Updates In-Reply-To: References: Message-ID: I have created account with wordpress.com. username is singhangrez. - Angrez On Tue, Feb 23, 2010 at 3:48 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Tue, Feb 23, 2010 at 8:14 AM, Angrez Singh wrote: > > I can edit the page, can someone let me know how to do that? > > Angrez, > > I have invited you to the blog. Please create an account (you should > receive e-mail from wordpress.com) so I can add you to watir.com blog. > Please let me know when you create the account, I am not sure if Wordpress > will let me know. > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Tue Feb 23 09:29:53 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 23 Feb 2010 15:29:53 +0100 Subject: [Wtr-development] Install Doc Updates In-Reply-To: References: Message-ID: On Tue, Feb 23, 2010 at 12:47 PM, Angrez Singh wrote: > I have created account with wordpress.com. username is singhangrez. I have added you to watir.com blog admins. You can log in at: http://watir.com/wp-admin/ Feel free to fix installation page according to comments. Please let me know if you need any help. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Tue Feb 23 09:52:41 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 23 Feb 2010 15:52:41 +0100 Subject: [Wtr-development] Resolved tickets in Jira In-Reply-To: References: <2a379a301002221609l7c419881ic664b1ee162dcb98@mail.gmail.com> Message-ID: On Tue, Feb 23, 2010 at 8:09 AM, Angrez Singh wrote: > I resolved most of the tickets that were moved from Google code to JIRA. Will go through them once again to see if anything is duplicate or can be resolved/closed. Thanks. We have 224 open tickets (55 in FireWatir), it would be great to resolve/close a few. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Tue Feb 23 10:21:33 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Tue, 23 Feb 2010 16:21:33 +0100 Subject: [Wtr-development] Resolved tickets in Jira In-Reply-To: <2a379a301002221609l7c419881ic664b1ee162dcb98@mail.gmail.com> References: <2a379a301002221609l7c419881ic664b1ee162dcb98@mail.gmail.com> Message-ID: On Tue, Feb 23, 2010 at 1:09 AM, Alan Baird wrote: > I tried to mark some of my tickets as closed. I don't know if I need permissions do do this or not but I couldn't find any option to close the ticket. Thanks for letting me know. You should see this: http://bit.ly/cp9DEV I will contact Patrick (admin of openqa.org) and let you know what he said. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Tue Feb 23 18:46:57 2010 From: bret at pettichord.com (Bret Pettichord) Date: Tue, 23 Feb 2010 17:46:57 -0600 Subject: [Wtr-development] Install Doc Updates In-Reply-To: References: Message-ID: Angrez, Thanks for your help with this. Bret On Tue, Feb 23, 2010 at 8:29 AM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Tue, Feb 23, 2010 at 12:47 PM, Angrez Singh wrote: > > I have created account with wordpress.com. username is singhangrez. > > I have added you to watir.com blog admins. You can log in at: > > http://watir.com/wp-admin/ > > Feel free to fix installation page according to comments. > > Please let me know if you need any help. > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From angrez at gmail.com Wed Feb 24 02:00:55 2010 From: angrez at gmail.com (Angrez Singh) Date: Wed, 24 Feb 2010 12:30:55 +0530 Subject: [Wtr-development] Install Doc Updates In-Reply-To: References: Message-ID: Not an issue Bret, at least I can do this much for Watir group. Not getting much time to get involved in development/changes/bug fixes. - Angrez On Wed, Feb 24, 2010 at 5:16 AM, Bret Pettichord wrote: > Angrez, > > Thanks for your help with this. > > Bret > > On Tue, Feb 23, 2010 at 8:29 AM, ?eljko Filipin < > zeljko.filipin at wa-research.ch> wrote: > >> On Tue, Feb 23, 2010 at 12:47 PM, Angrez Singh wrote: >> > I have created account with wordpress.com. username is singhangrez. >> >> I have added you to watir.com blog admins. You can log in at: >> >> http://watir.com/wp-admin/ >> >> Feel free to fix installation page according to comments. >> >> Please let me know if you need any help. >> >> ?eljko >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angrez at gmail.com Wed Feb 24 02:41:59 2010 From: angrez at gmail.com (Angrez Singh) Date: Wed, 24 Feb 2010 13:11:59 +0530 Subject: [Wtr-development] Install Doc Updates In-Reply-To: References: Message-ID: I have updated the installation document with suggestions provided in the comments. Let me know if everything looks fine or we need to modify. - Angrez On Wed, Feb 24, 2010 at 12:30 PM, Angrez Singh wrote: > Not an issue Bret, at least I can do this much for Watir group. Not getting > much time to get involved in development/changes/bug fixes. > > - Angrez > > > On Wed, Feb 24, 2010 at 5:16 AM, Bret Pettichord wrote: > >> Angrez, >> >> Thanks for your help with this. >> >> Bret >> >> On Tue, Feb 23, 2010 at 8:29 AM, ?eljko Filipin < >> zeljko.filipin at wa-research.ch> wrote: >> >>> On Tue, Feb 23, 2010 at 12:47 PM, Angrez Singh wrote: >>> > I have created account with wordpress.com. username is singhangrez. >>> >>> I have added you to watir.com blog admins. You can log in at: >>> >>> http://watir.com/wp-admin/ >>> >>> Feel free to fix installation page according to comments. >>> >>> Please let me know if you need any help. >>> >>> ?eljko >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Wed Feb 24 05:47:39 2010 From: alister.scott at gmail.com (Alister Scott) Date: Wed, 24 Feb 2010 20:47:39 +1000 Subject: [Wtr-development] Install Doc Updates In-Reply-To: References: Message-ID: <16bf298e1002240247y6949b058o98e8793e2ce9cfcb@mail.gmail.com> Looks great. Thanks. 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 Wed, Feb 24, 2010 at 5:41 PM, Angrez Singh wrote: > I have updated the installation document with suggestions provided in the > comments. Let me know if everything looks fine or we need to modify. > > - Angrez > > > On Wed, Feb 24, 2010 at 12:30 PM, Angrez Singh wrote: > >> Not an issue Bret, at least I can do this much for Watir group. Not >> getting much time to get involved in development/changes/bug fixes. >> >> - Angrez >> >> >> On Wed, Feb 24, 2010 at 5:16 AM, Bret Pettichord wrote: >> >>> Angrez, >>> >>> Thanks for your help with this. >>> >>> Bret >>> >>> On Tue, Feb 23, 2010 at 8:29 AM, ?eljko Filipin < >>> zeljko.filipin at wa-research.ch> wrote: >>> >>>> On Tue, Feb 23, 2010 at 12:47 PM, Angrez Singh >>>> wrote: >>>> > I have created account with wordpress.com. username is singhangrez. >>>> >>>> I have added you to watir.com blog admins. You can log in at: >>>> >>>> http://watir.com/wp-admin/ >>>> >>>> Feel free to fix installation page according to comments. >>>> >>>> Please let me know if you need any help. >>>> >>>> ?eljko >>>> >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development at 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 at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Wed Feb 24 07:31:47 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 24 Feb 2010 13:31:47 +0100 Subject: [Wtr-development] Install Doc Updates In-Reply-To: References: Message-ID: On Wed, Feb 24, 2010 at 8:41 AM, Angrez Singh wrote: > I have updated the installation document with suggestions provided in the comments. Thanks. > Let me know if everything looks fine or we need to modify. Please remove this from Mac section, Mac does not have apt-get: sudo apt-get install ruby sudo apt-get install rubygems ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Wed Feb 24 10:31:06 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 24 Feb 2010 09:31:06 -0600 Subject: [Wtr-development] Recommended Ruby Version Message-ID: 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 Twitter, www.twitter.com/bpettichord -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at wa-research.ch Wed Feb 24 11:03:12 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Wed, 24 Feb 2010 17:03:12 +0100 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: Message-ID: On Wed, Feb 24, 2010 at 4:31 PM, Bret Pettichord wrote: > 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. In that case, I vote for 1.8.7. ?eljko -- watir.com - community manager pledgie.com/campaigns/2982 - donate to Watir watirpodcast.com - host testingpodcast.com - podcasts on software testing. all of them -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Wed Feb 24 11:32:28 2010 From: notethan at gmail.com (Ethan) Date: Wed, 24 Feb 2010 11:32:28 -0500 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: Message-ID: 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 => #> >> 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 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 > Twitter, www.twitter.com/bpettichord > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Wed Feb 24 12:13:04 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 24 Feb 2010 11:13:04 -0600 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: Message-ID: 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 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 > => #> > >> 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 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 >> Twitter, www.twitter.com/bpettichord >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Wed Feb 24 12:37:57 2010 From: notethan at gmail.com (Ethan) Date: Wed, 24 Feb 2010 12:37:57 -0500 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: Message-ID: 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 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 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 >> => #> >> >> 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 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 >>> Twitter, www.twitter.com/bpettichord >>> >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Wed Feb 24 12:55:26 2010 From: notethan at gmail.com (Ethan) Date: Wed, 24 Feb 2010 12:55:26 -0500 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: Message-ID: 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 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 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 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 >>> => #> >>> >> 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 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 >>>> Twitter, www.twitter.com/bpettichord >>>> >>>> >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>> >>> >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angrez at gmail.com Wed Feb 24 13:06:39 2010 From: angrez at gmail.com (Angrez Singh) Date: Wed, 24 Feb 2010 23:36:39 +0530 Subject: [Wtr-development] Install Doc Updates In-Reply-To: References: Message-ID: Done ?eljko, can you check & see if everything is fine now. - Angrez On Wed, Feb 24, 2010 at 6:01 PM, ?eljko Filipin < zeljko.filipin at wa-research.ch> wrote: > On Wed, Feb 24, 2010 at 8:41 AM, Angrez Singh wrote: > > I have updated the installation document with suggestions provided in the > comments. > > Thanks. > > > > Let me know if everything looks fine or we need to modify. > > Please remove this from Mac section, Mac does not have apt-get: > > sudo apt-get install ruby > sudo apt-get install rubygems > > ?eljko > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charley.baker at gmail.com Wed Feb 24 13:36:49 2010 From: charley.baker at gmail.com (Charley Baker) Date: Wed, 24 Feb 2010 11:36:49 -0700 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: Message-ID: Can you mention this on the ruby installer mailing list? This is at the very least inconsistent, I believe i duped it on a Mac compile of ruby. Worth looking at anyhow. -c On Wed, Feb 24, 2010 at 10:55 AM, Ethan 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 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 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 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 >>>> => #> >>>> >> 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 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 >>>>> Twitter, www.twitter.com/bpettichord >>>>> >>>>> >>>>> _______________________________________________ >>>>> Wtr-development mailing list >>>>> Wtr-development at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development at 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 at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Wed Feb 24 17:41:27 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 24 Feb 2010 16:41:27 -0600 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: Message-ID: 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 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 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 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 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 >>>> => #> >>>> >> 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 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 >>>>> Twitter, www.twitter.com/bpettichord >>>>> >>>>> >>>>> _______________________________________________ >>>>> Wtr-development mailing list >>>>> Wtr-development at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development at 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 at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> > > _______________________________________________ > Wtr-development mailing list > Wtr-development at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Wed Feb 24 17:53:59 2010 From: alister.scott at gmail.com (Alister Scott) Date: Thu, 25 Feb 2010 08:53:59 +1000 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: Message-ID: <16bf298e1002241453u426ebddwae903518146efe2f@mail.gmail.com> 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 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 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 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 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 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 >>>>> => #> >>>>> >> 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 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 >>>>>> Twitter, www.twitter.com/bpettichord >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Wtr-development mailing list >>>>>> Wtr-development at rubyforge.org >>>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Wtr-development mailing list >>>>> Wtr-development at 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 at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>> >>> >>> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Wed Feb 24 19:36:48 2010 From: alister.scott at gmail.com (Alister Scott) Date: Thu, 25 Feb 2010 10:36:48 +1000 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: <16bf298e1002241453u426ebddwae903518146efe2f@mail.gmail.com> References: <16bf298e1002241453u426ebddwae903518146efe2f@mail.gmail.com> Message-ID: <16bf298e1002241636r5fe7d0a1wf9aa58bf0a9fdade@mail.gmail.com> 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 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 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 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 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 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 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 >>>>>> => #> >>>>>> >> 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 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 >>>>>>> Twitter, www.twitter.com/bpettichord >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Wtr-development mailing list >>>>>>> Wtr-development at rubyforge.org >>>>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Wtr-development mailing list >>>>>> Wtr-development at 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 at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Thu Feb 25 00:08:32 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 24 Feb 2010 23:08:32 -0600 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: <16bf298e1002241636r5fe7d0a1wf9aa58bf0a9fdade@mail.gmail.com> References: <16bf298e1002241453u426ebddwae903518146efe2f@mail.gmail.com> <16bf298e1002241636r5fe7d0a1wf9aa58bf0a9fdade@mail.gmail.com> Message-ID: 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 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 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 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 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 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 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 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 >>>>>>> => #> >>>>>>> >> 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 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 >>>>>>>> Twitter, www.twitter.com/bpettichord >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Wtr-development mailing list >>>>>>>> Wtr-development at rubyforge.org >>>>>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Wtr-development mailing list >>>>>>> Wtr-development at 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 at rubyforge.org >>>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development at 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 at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> > > _______________________________________________ > Wtr-development mailing list > Wtr-development at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Thu Feb 25 00:26:43 2010 From: alister.scott at gmail.com (Alister Scott) Date: Thu, 25 Feb 2010 15:26:43 +1000 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: <16bf298e1002241453u426ebddwae903518146efe2f@mail.gmail.com> <16bf298e1002241636r5fe7d0a1wf9aa58bf0a9fdade@mail.gmail.com> Message-ID: <16bf298e1002242126n6470b8e9w4a9899c2bba78079@mail.gmail.com> Hi Bret, Originally I thought it was a timeout issue, but when I run it I can't actually see the dialog open, so the problem is click_no_wait isn't clicking *and* not reporting an error. Does that make sense? 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 3:08 PM, Bret Pettichord wrote: > 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 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 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 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 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 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 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 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 >>>>>>>> => #> >>>>>>>> >> 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 >>>>>>> > 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 >>>>>>>>> Twitter, www.twitter.com/bpettichord >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Wtr-development mailing list >>>>>>>>> Wtr-development at rubyforge.org >>>>>>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Wtr-development mailing list >>>>>>>> Wtr-development at 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 at rubyforge.org >>>>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Wtr-development mailing list >>>>> Wtr-development at 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 at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>> >>> >>> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Thu Feb 25 00:38:36 2010 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 24 Feb 2010 23:38:36 -0600 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: <16bf298e1002242126n6470b8e9w4a9899c2bba78079@mail.gmail.com> References: <16bf298e1002241453u426ebddwae903518146efe2f@mail.gmail.com> <16bf298e1002241636r5fe7d0a1wf9aa58bf0a9fdade@mail.gmail.com> <16bf298e1002242126n6470b8e9w4a9899c2bba78079@mail.gmail.com> Message-ID: Well, like I said it is working for me. By design, click_no_wait will not report an error if it has one. It executes in a separate process, so any errors occur in that process. Do you see the same problem when you use Ruby 1.8.6-26? Bret On Wed, Feb 24, 2010 at 11:26 PM, Alister Scott wrote: > Hi Bret, > > Originally I thought it was a timeout issue, but when I run it I can't > actually see the dialog open, so the problem is click_no_wait isn't clicking > *and* not reporting an error. > > Does that make sense? > > > 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 3:08 PM, Bret Pettichord wrote: > >> 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 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 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 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 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 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 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 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 >>>>>>>>> => #> >>>>>>>>> >> 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 < >>>>>>>>> bret at 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 >>>>>>>>>> Twitter, www.twitter.com/bpettichord >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Wtr-development mailing list >>>>>>>>>> Wtr-development at rubyforge.org >>>>>>>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Wtr-development mailing list >>>>>>>>> Wtr-development at 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 at rubyforge.org >>>>>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Wtr-development mailing list >>>>>> Wtr-development at 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 at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Thu Feb 25 01:05:12 2010 From: alister.scott at gmail.com (Alister Scott) Date: Thu, 25 Feb 2010 16:05:12 +1000 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: <16bf298e1002241453u426ebddwae903518146efe2f@mail.gmail.com> <16bf298e1002241636r5fe7d0a1wf9aa58bf0a9fdade@mail.gmail.com> <16bf298e1002242126n6470b8e9w4a9899c2bba78079@mail.gmail.com> Message-ID: <16bf298e1002242205q3e53b1beu1066b1cb8d07cc@mail.gmail.com> I have tried it and it works fine in 1.8.6.26 To prove it's not related to the timeout, I tried this basic script, and it still doesn't actually perform the click require 'watir' ie = Watir::IE.new ie.goto('www.google.com') ie.text_field(:name, 'q').set 'watir' ie.button(:value, 'Google Search').click_no_wait Thanks, 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 3:38 PM, Bret Pettichord wrote: > Well, like I said it is working for me. > > By design, click_no_wait will not report an error if it has one. It > executes in a separate process, so any errors occur in that process. > > Do you see the same problem when you use Ruby 1.8.6-26? > > Bret > > > On Wed, Feb 24, 2010 at 11:26 PM, Alister Scott wrote: > >> Hi Bret, >> >> Originally I thought it was a timeout issue, but when I run it I can't >> actually see the dialog open, so the problem is click_no_wait isn't clicking >> *and* not reporting an error. >> >> Does that make sense? >> >> >> 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 3:08 PM, Bret Pettichord wrote: >> >>> 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 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 >>> > 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 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 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 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 >>>>>>> > 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 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 >>>>>>>>>> => #> >>>>>>>>>> >> 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 < >>>>>>>>>> bret at 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 >>>>>>>>>>> Twitter, www.twitter.com/bpettichord >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Wtr-development mailing list >>>>>>>>>>> Wtr-development at rubyforge.org >>>>>>>>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Wtr-development mailing list >>>>>>>>>> Wtr-development at 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 at rubyforge.org >>>>>>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Wtr-development mailing list >>>>>>> Wtr-development at 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 at rubyforge.org >>>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development at 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 at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Thu Feb 25 02:07:43 2010 From: jarmo.p at gmail.com (Jarmo) Date: Thu, 25 Feb 2010 09:07:43 +0200 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: <16bf298e1002242205q3e53b1beu1066b1cb8d07cc@mail.gmail.com> References: <16bf298e1002241453u426ebddwae903518146efe2f@mail.gmail.com> <16bf298e1002241636r5fe7d0a1wf9aa58bf0a9fdade@mail.gmail.com> <16bf298e1002242126n6470b8e9w4a9899c2bba78079@mail.gmail.com> <16bf298e1002242205q3e53b1beu1066b1cb8d07cc@mail.gmail.com> Message-ID: 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 wrote: > I have tried it and it works fine in 1.8.6.26 > > To prove it's not related to the timeout, I tried this basic script, and it > still doesn't actually perform the click > > require 'watir' > ie = Watir::IE.new > ie.goto('www.google.com') > ie.text_field(:name, 'q').set 'watir' > ie.button(:value, 'Google Search').click_no_wait > > Thanks, > > 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 3:38 PM, Bret Pettichord > wrote: >> >> Well, like I said it is working for me. >> >> By design, click_no_wait will not report an error if it has one. It >> executes in a separate process, so any errors occur in that process. >> >> Do you see the same problem when you use Ruby 1.8.6-26? >> >> Bret >> >> On Wed, Feb 24, 2010 at 11:26 PM, Alister Scott >> wrote: >>> >>> Hi Bret, >>> >>> Originally I thought it was a timeout issue, but when I run it I can't >>> actually see the dialog open, so the problem is click_no_wait isn't clicking >>> and not reporting an error. >>> >>> Does that make sense? >>> >>> 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 3:08 PM, Bret Pettichord >>> wrote: >>>> >>>> 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 >>>> 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 >>>>> 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 >>>>>> 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 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 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 >>>>>>>>> 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 >>>>>>>>>> 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 >>>>>>>>>>> => #> >>>>>>>>>>> >> 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 >>>>>>>>>>> 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 >>>>>>>>>>>> Twitter, www.twitter.com/bpettichord >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Wtr-development mailing list >>>>>>>>>>>> Wtr-development at rubyforge.org >>>>>>>>>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Wtr-development mailing list >>>>>>>>>>> Wtr-development at 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 at rubyforge.org >>>>>>>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Wtr-development mailing list >>>>>>>> Wtr-development at 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 at rubyforge.org >>>>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Wtr-development mailing list >>>>> Wtr-development at 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 at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From bret at pettichord.com Thu Feb 25 03:05:42 2010 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 25 Feb 2010 02:05:42 -0600 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: <16bf298e1002241453u426ebddwae903518146efe2f@mail.gmail.com> <16bf298e1002241636r5fe7d0a1wf9aa58bf0a9fdade@mail.gmail.com> <16bf298e1002242126n6470b8e9w4a9899c2bba78079@mail.gmail.com> <16bf298e1002242205q3e53b1beu1066b1cb8d07cc@mail.gmail.com> Message-ID: Brilliant! On Feb 25, 2010 1:26 AM, "Jarmo" 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 wrote: > I have tried it a... -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Thu Feb 25 05:02:42 2010 From: alister.scott at gmail.com (Alister Scott) Date: Thu, 25 Feb 2010 20:02:42 +1000 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: <16bf298e1002241453u426ebddwae903518146efe2f@mail.gmail.com> <16bf298e1002241636r5fe7d0a1wf9aa58bf0a9fdade@mail.gmail.com> <16bf298e1002242126n6470b8e9w4a9899c2bba78079@mail.gmail.com> <16bf298e1002242205q3e53b1beu1066b1cb8d07cc@mail.gmail.com> Message-ID: <16bf298e1002250202t5841cd13ha66b8b53b98067a0@mail.gmail.com> 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 wrote: > Brilliant! > > On Feb 25, 2010 1:26 AM, "Jarmo" 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 > wrote: > > I have tried it a... > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Thu Feb 25 05:38:09 2010 From: jarmo.p at gmail.com (Jarmo) Date: Thu, 25 Feb 2010 12:38:09 +0200 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: <16bf298e1002250202t5841cd13ha66b8b53b98067a0@mail.gmail.com> References: <16bf298e1002241453u426ebddwae903518146efe2f@mail.gmail.com> <16bf298e1002241636r5fe7d0a1wf9aa58bf0a9fdade@mail.gmail.com> <16bf298e1002242126n6470b8e9w4a9899c2bba78079@mail.gmail.com> <16bf298e1002242205q3e53b1beu1066b1cb8d07cc@mail.gmail.com> <16bf298e1002250202t5841cd13ha66b8b53b98067a0@mail.gmail.com> Message-ID: This seems to be something similar to the Ethan's examples... Or? Jarmo On Thu, Feb 25, 2010 at 12:02 PM, Alister Scott 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 > wrote: >> >> Brilliant! >> >> On Feb 25, 2010 1:26 AM, "Jarmo" 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 >> wrote: >> > I have tried it a... >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From zeljko.filipin at wa-research.ch Thu Feb 25 06:14:37 2010 From: zeljko.filipin at wa-research.ch (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 25 Feb 2010 12:14:37 +0100 Subject: [Wtr-development] Install Doc Updates In-Reply-To: References: Message-ID: On Wed, Feb 24, 2010 at 7:06 PM, Angrez Singh wrote: > Done ?eljko, can you check & see if everything is fine now. Thanks, it looks good. I have some (good) news, it is related to this thread, so I am not starting a new one. In the next few days I will be writing an article for vidi.hr (Croatian print computer magazine) on how to install Watir. I plan to cover all platforms and browsers, including watir-webdriver and Celerity. If time permits, I plan to record a screencast on how to install Watir. (Installation page is the second most viewed page on watir.com, after the home page, according to wordpress.com stats, so I guess it is interesting to people). I will also update installation page with watir-webdriver and Celerity. I have two questions: 1) Could somebody recommend a tool for recording screencasts? I would prefer if the tool was open source, free, or had a free trial, so I can try before buying. I want to record screen and myself talking (like fosscasts.com). (I have already contacted fosscasts.com and I know how they do it, I am wondering if there are alternatives). 2) Does anybody know how to install Mac OS in virtual machine? I know that is a gray area, I am not sure how legal that is. I have Apple hardware and Mac OS 10.5 and 10.6 install DVD. I just want to see how Watir installation would go for a clean Mac machine, and I do not want to break my current Mac OS installation. ?eljko -------------- next part -------------- An HTML attachment was scrubbed... URL: From notethan at gmail.com Thu Feb 25 11:00:12 2010 From: notethan at gmail.com (Ethan) Date: Thu, 25 Feb 2010 11:00:12 -0500 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: <16bf298e1002241636r5fe7d0a1wf9aa58bf0a9fdade@mail.gmail.com> <16bf298e1002242126n6470b8e9w4a9899c2bba78079@mail.gmail.com> <16bf298e1002242205q3e53b1beu1066b1cb8d07cc@mail.gmail.com> <16bf298e1002250202t5841cd13ha66b8b53b98067a0@mail.gmail.com> Message-ID: 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 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 > 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 > > wrote: > >> > >> Brilliant! > >> > >> On Feb 25, 2010 1:26 AM, "Jarmo" 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 > > >> wrote: > >> > I have tried it a... > >> > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Thu Feb 25 17:38:55 2010 From: alister.scott at gmail.com (Alister Scott) Date: Fri, 26 Feb 2010 08:38:55 +1000 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: <16bf298e1002242126n6470b8e9w4a9899c2bba78079@mail.gmail.com> <16bf298e1002242205q3e53b1beu1066b1cb8d07cc@mail.gmail.com> <16bf298e1002250202t5841cd13ha66b8b53b98067a0@mail.gmail.com> Message-ID: <16bf298e1002251438i6ef898fcn1918daa920de7710@mail.gmail.com> 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 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 { 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 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 >> 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 >> > wrote: >> >> >> >> Brilliant! >> >> >> >> On Feb 25, 2010 1:26 AM, "Jarmo" 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.scott at gmail.com> >> >> wrote: >> >> > I have tried it a... >> >> >> >> _______________________________________________ >> >> Wtr-development mailing list >> >> Wtr-development at rubyforge.org >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> > >> > >> > _______________________________________________ >> > Wtr-development mailing list >> > Wtr-development at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/wtr-development >> > >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Thu Feb 25 18:44:17 2010 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 25 Feb 2010 17:44:17 -0600 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: <16bf298e1002251438i6ef898fcn1918daa920de7710@mail.gmail.com> References: <16bf298e1002242126n6470b8e9w4a9899c2bba78079@mail.gmail.com> <16bf298e1002242205q3e53b1beu1066b1cb8d07cc@mail.gmail.com> <16bf298e1002250202t5841cd13ha66b8b53b98067a0@mail.gmail.com> <16bf298e1002251438i6ef898fcn1918daa920de7710@mail.gmail.com> Message-ID: 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 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 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> { 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 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 >>> 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 >>> > wrote: >>> >> >>> >> Brilliant! >>> >> >>> >> On Feb 25, 2010 1:26 AM, "Jarmo" 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.scott at gmail.com> >>> >> wrote: >>> >> > I have tried it a... >>> >> >>> >> _______________________________________________ >>> >> Wtr-development mailing list >>> >> Wtr-development at rubyforge.org >>> >> http://rubyforge.org/mailman/listinfo/wtr-development >>> > >>> > >>> > _______________________________________________ >>> > Wtr-development mailing list >>> > Wtr-development at rubyforge.org >>> > http://rubyforge.org/mailman/listinfo/wtr-development >>> > >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Fri Feb 26 06:31:29 2010 From: jarmo.p at gmail.com (Jarmo) Date: Fri, 26 Feb 2010 13:31:29 +0200 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: <16bf298e1002242205q3e53b1beu1066b1cb8d07cc@mail.gmail.com> <16bf298e1002250202t5841cd13ha66b8b53b98067a0@mail.gmail.com> <16bf298e1002251438i6ef898fcn1918daa920de7710@mail.gmail.com> Message-ID: 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 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 > 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 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>> ??? { 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 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 >>>> 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 >>>> > wrote: >>>> >> >>>> >> Brilliant! >>>> >> >>>> >> On Feb 25, 2010 1:26 AM, "Jarmo" 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 >>>> >> >>>> >> wrote: >>>> >> > I have tried it a... >>>> >> >>>> >> _______________________________________________ >>>> >> Wtr-development mailing list >>>> >> Wtr-development at rubyforge.org >>>> >> http://rubyforge.org/mailman/listinfo/wtr-development >>>> > >>>> > >>>> > _______________________________________________ >>>> > Wtr-development mailing list >>>> > Wtr-development at rubyforge.org >>>> > http://rubyforge.org/mailman/listinfo/wtr-development >>>> > >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From billagee at gmail.com Fri Feb 26 15:31:46 2010 From: billagee at gmail.com (Bill Agee) Date: Fri, 26 Feb 2010 12:31:46 -0800 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: <16bf298e1002242205q3e53b1beu1066b1cb8d07cc@mail.gmail.com> <16bf298e1002250202t5841cd13ha66b8b53b98067a0@mail.gmail.com> <16bf298e1002251438i6ef898fcn1918daa920de7710@mail.gmail.com> Message-ID: <73e7817e1002261231y6bd40754sfdf6548dea3c1750@mail.gmail.com> 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 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 > 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 > > 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 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 >>> { 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 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 > >>>> 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 < > bret at pettichord.com> > >>>> > wrote: > >>>> >> > >>>> >> Brilliant! > >>>> >> > >>>> >> On Feb 25, 2010 1:26 AM, "Jarmo" 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 > >>>> >> > >>>> >> wrote: > >>>> >> > I have tried it a... > >>>> >> > >>>> >> _______________________________________________ > >>>> >> Wtr-development mailing list > >>>> >> Wtr-development at rubyforge.org > >>>> >> http://rubyforge.org/mailman/listinfo/wtr-development > >>>> > > >>>> > > >>>> > _______________________________________________ > >>>> > Wtr-development mailing list > >>>> > Wtr-development at rubyforge.org > >>>> > http://rubyforge.org/mailman/listinfo/wtr-development > >>>> > > >>>> _______________________________________________ > >>>> Wtr-development mailing list > >>>> Wtr-development at rubyforge.org > >>>> http://rubyforge.org/mailman/listinfo/wtr-development > >>> > >>> > >>> _______________________________________________ > >>> Wtr-development mailing list > >>> Wtr-development at rubyforge.org > >>> http://rubyforge.org/mailman/listinfo/wtr-development > >> > >> > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at 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 at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarmo.p at gmail.com Sun Feb 28 05:23:38 2010 From: jarmo.p at gmail.com (Jarmo) Date: Sun, 28 Feb 2010 12:23:38 +0200 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: <73e7817e1002261231y6bd40754sfdf6548dea3c1750@mail.gmail.com> References: <16bf298e1002250202t5841cd13ha66b8b53b98067a0@mail.gmail.com> <16bf298e1002251438i6ef898fcn1918daa920de7710@mail.gmail.com> <73e7817e1002261231y6bd40754sfdf6548dea3c1750@mail.gmail.com> Message-ID: 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 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 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 >> 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 >> > 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 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> >>> ??? { 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 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 >> >>>> 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 >> >>>> > >> >>>> > wrote: >> >>>> >> >> >>>> >> Brilliant! >> >>>> >> >> >>>> >> On Feb 25, 2010 1:26 AM, "Jarmo" 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 >> >>>> >> >> >>>> >> wrote: >> >>>> >> > I have tried it a... >> >>>> >> >> >>>> >> _______________________________________________ >> >>>> >> Wtr-development mailing list >> >>>> >> Wtr-development at rubyforge.org >> >>>> >> http://rubyforge.org/mailman/listinfo/wtr-development >> >>>> > >> >>>> > >> >>>> > _______________________________________________ >> >>>> > Wtr-development mailing list >> >>>> > Wtr-development at rubyforge.org >> >>>> > http://rubyforge.org/mailman/listinfo/wtr-development >> >>>> > >> >>>> _______________________________________________ >> >>>> Wtr-development mailing list >> >>>> Wtr-development at rubyforge.org >> >>>> http://rubyforge.org/mailman/listinfo/wtr-development >> >>> >> >>> >> >>> _______________________________________________ >> >>> Wtr-development mailing list >> >>> Wtr-development at rubyforge.org >> >>> http://rubyforge.org/mailman/listinfo/wtr-development >> >> >> >> >> >> _______________________________________________ >> >> Wtr-development mailing list >> >> Wtr-development at 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 at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/wtr-development >> > >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > From jasnow at hotmail.com Sun Feb 28 13:46:01 2010 From: jasnow at hotmail.com (Al Snow) Date: Sun, 28 Feb 2010 13:46:01 -0500 Subject: [Wtr-development] My work on watir-webdriver (especially safari driver) Message-ID: Everyone, For the past several weeks, I have been working with the new version of Watir (watir-webdriver). I have documented my journey on my wiki and one of my blogs (Chapters 51-58, see last one for current summary). Now it is time to check in and verify what other people have been doing in this area (especially with the safari driver for watir-webdriver) and see if other people would like to help to create a "branch" (fork) for this work. I will update my blog with the responses and post to the wtr-development and webdriver e-groups. Thanks in advance, Al Snow Linkedin: http://www.linkedin.com/in/alsnow Google Talk: jasnow1 Twitter: jasnow PS. Remember to include : Twitter: @safariwatir IRC: #watir E-groups: wtr-development at rubyforge.org watir-general at googlegroups.com webdriver at googlegroups.com selenium-developers at googlegroups.com Three main developers: Jari, Simon, Tom _________________________________________________________________ Hotmail: Trusted email with Microsoft?s powerful SPAM protection. http://clk.atdmt.com/GBL/go/201469226/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From charley.baker at gmail.com Sun Feb 28 17:55:06 2010 From: charley.baker at gmail.com (Charley Baker) Date: Sun, 28 Feb 2010 15:55:06 -0700 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: <16bf298e1002250202t5841cd13ha66b8b53b98067a0@mail.gmail.com> <16bf298e1002251438i6ef898fcn1918daa920de7710@mail.gmail.com> <73e7817e1002261231y6bd40754sfdf6548dea3c1750@mail.gmail.com> Message-ID: 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 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 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 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 > >> 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.scott at 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 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 >> >>> { 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 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 > >> >>>> 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 > >> >>>> > > >> >>>> > wrote: > >> >>>> >> > >> >>>> >> Brilliant! > >> >>>> >> > >> >>>> >> On Feb 25, 2010 1:26 AM, "Jarmo" 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 > >> >>>> >> > >> >>>> >> wrote: > >> >>>> >> > I have tried it a... > >> >>>> >> > >> >>>> >> _______________________________________________ > >> >>>> >> Wtr-development mailing list > >> >>>> >> Wtr-development at rubyforge.org > >> >>>> >> http://rubyforge.org/mailman/listinfo/wtr-development > >> >>>> > > >> >>>> > > >> >>>> > _______________________________________________ > >> >>>> > Wtr-development mailing list > >> >>>> > Wtr-development at rubyforge.org > >> >>>> > http://rubyforge.org/mailman/listinfo/wtr-development > >> >>>> > > >> >>>> _______________________________________________ > >> >>>> Wtr-development mailing list > >> >>>> Wtr-development at rubyforge.org > >> >>>> http://rubyforge.org/mailman/listinfo/wtr-development > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> Wtr-development mailing list > >> >>> Wtr-development at rubyforge.org > >> >>> http://rubyforge.org/mailman/listinfo/wtr-development > >> >> > >> >> > >> >> _______________________________________________ > >> >> Wtr-development mailing list > >> >> Wtr-development at 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 at rubyforge.org > >> > http://rubyforge.org/mailman/listinfo/wtr-development > >> > > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alister.scott at gmail.com Sun Feb 28 17:58:54 2010 From: alister.scott at gmail.com (Alister Scott) Date: Mon, 1 Mar 2010 08:58:54 +1000 Subject: [Wtr-development] Recommended Ruby Version In-Reply-To: References: <16bf298e1002250202t5841cd13ha66b8b53b98067a0@mail.gmail.com> <16bf298e1002251438i6ef898fcn1918daa920de7710@mail.gmail.com> <73e7817e1002261231y6bd40754sfdf6548dea3c1750@mail.gmail.com> Message-ID: <16bf298e1002281458m14dafe61sa7753269d947fb48@mail.gmail.com> Sounds like a good idea to me. Cheers, Alister On Mon, Mar 1, 2010 at 8:55 AM, Charley Baker 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 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 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 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 >> >> 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.scott at 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 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> >> >>> { 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 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 >> >> >>>> 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 >> >> >>>> > >> >> >>>> > wrote: >> >> >>>> >> >> >> >>>> >> Brilliant! >> >> >>>> >> >> >> >>>> >> On Feb 25, 2010 1:26 AM, "Jarmo" 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 >> >> >>>> >> >> >> >>>> >> wrote: >> >> >>>> >> > I have tried it a... >> >> >>>> >> >> >> >>>> >> _______________________________________________ >> >> >>>> >> Wtr-development mailing list >> >> >>>> >> Wtr-development at rubyforge.org >> >> >>>> >> http://rubyforge.org/mailman/listinfo/wtr-development >> >> >>>> > >> >> >>>> > >> >> >>>> > _______________________________________________ >> >> >>>> > Wtr-development mailing list >> >> >>>> > Wtr-development at rubyforge.org >> >> >>>> > http://rubyforge.org/mailman/listinfo/wtr-development >> >> >>>> > >> >> >>>> _______________________________________________ >> >> >>>> Wtr-development mailing list >> >> >>>> Wtr-development at rubyforge.org >> >> >>>> http://rubyforge.org/mailman/listinfo/wtr-development >> >> >>> >> >> >>> >> >> >>> _______________________________________________ >> >> >>> Wtr-development mailing list >> >> >>> Wtr-development at rubyforge.org >> >> >>> http://rubyforge.org/mailman/listinfo/wtr-development >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> Wtr-development mailing list >> >> >> Wtr-development at 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 at rubyforge.org >> >> > http://rubyforge.org/mailman/listinfo/wtr-development >> >> > >> >> _______________________________________________ >> >> Wtr-development mailing list >> >> Wtr-development at rubyforge.org >> >> http://rubyforge.org/mailman/listinfo/wtr-development >> > >> > >> > _______________________________________________ >> > Wtr-development mailing list >> > Wtr-development at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/wtr-development >> > >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development at rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: