Hi Bill, well at first it might be helpful to try the solution/patch provided in the bug or in my e-mail and see if it's going to happen ever again :)
also, the require 'rubygems' statement might be a thing to strongly consider adding if you think of it... Jarmo On Thu, Mar 25, 2010 at 9:24 PM, Bill Agee <[email protected]> wrote: > Hi Jarmo, > > I closed this bug (WTR-320) a while back since I could not repro it anymore > in Watir 1.6.5 using Win7 Ultimate 32-bit. > > But as you mentioned, it looks like this still reproduces on other Windows > OS releases. :) So I reopened the bug today. > > Looks like this one cannot really be closed until it no longer repros on (at > least) Win7 Ultiimate, Win7 Pro, and WinXP Pro. Probably the Vista flavors > as well. > > Thanks > Bill > > > On Thu, Mar 25, 2010 at 11:26 AM, Jarmo <[email protected]> wrote: >> >> Hi. >> >> I encountered a problem when tried to use click_no_wait. I used my own >> debugging techniques >> >> (http://www.itreallymatters.net/post/378669758/debugging-watirs-click-no-wait-method-problems) >> and got this error message from Ruby: >> -e:1: unterminated string meets end of file >> >> Anyway, it is strange, because the same code worked on one PC and >> didn't work on another. System configurations are as following: >> >> PC #1, where everything worked as they are: >> Windows 7 Ultimate 64bit >> ruby 1.8.6 (2010-02-04 patchlevel 398) [i386-mingw32] >> >> And the PC #2, where it didn't work: >> Windows 7 Professional 32bit >> ruby 1.8.6 (2010-02-04 patchlevel 398) [i386-mingw32] >> >> So, the only difference seems to be in 32/64 bit and >> Professional/Ultimate. >> >> So i started investigating and in the end made a patch which fixed it. >> After that I googled around and saw that there has been already done >> same patch in the past. It is actually in JIRA: >> http://jira.openqa.org/browse/WTR-320 >> >> The same bug got already mentioned in one of our previous lengthy >> thread called "Recommended Ruby Version" >> (http://www.mail-archive.com/[email protected]/msg00298.html), >> but I didn't know at that time that it is the same problem, because it >> didn't have the same error message mentioned in it. >> >> Anyway, creating that patch helped me to solve my problem and now it's >> working on both PC-s. Another question is that why is it stated as >> "Fixed" in JIRA in Watir 1.6.5, when it isn't? >> >> Also, in Watir's repo (if that is official repo - >> >> http://github.com/bret/watir/blob/master/watir/lib/watir/page-container.rb) >> there isn't that patch applied either. Is it somehow gone missing? >> Didn't see anything related to that in git history either... >> >> Also, when talking about the method called eval_in_spawned_process in >> page_container.rb, then it seems that it is only used by click_no_wait >> and one test, which means that in my opinion we could simplify it to >> some degree. At least i couldn't think of the reason why it is >> currently as it is - essentially, why is this load_path_code variable >> used there at all? >> >> Currently the solution is like this: >> def eval_in_spawned_process(command) >> command.strip! >> load_path_code = _code_that_copies_readonly_array($LOAD_PATH, >> '$LOAD_PATH') >> ruby_code = "require 'watir/ie'; " >> # ruby_code = "$HIDE_IE = #{$HIDE_IE};" # This prevents attaching >> to a window from setting it visible. However modal dialogs cannot be >> attached to when not visible. >> ruby_code << "pc = #{attach_command}; " # pc = page container >> # IDEA: consider changing this to not use instance_eval (it >> makes the code hard to understand) >> ruby_code << "pc.instance_eval(#{command.inspect})" >> exec_string = "start rubyw -e #{(load_path_code + '; ' + >> ruby_code).inspect}" >> system(exec_string) >> end >> >> My proposed solution would be like this: >> def eval_in_spawned_process(command) >> command.strip! >> ruby_code = "require 'watir/ie';" >> ruby_code << "pc = #{attach_command};" # pc = page container >> ruby_code << "pc.instance_eval(#{command.inspect})" >> exec_string = "start rubyw -e #{ruby_code.gsub('"','\'').inspect}" >> system(exec_string) >> end >> >> This is working for me and i won about 1 second while performing the >> click. Also i don't see a reason why this load path would be copied at >> all. Maybe someone has the explanation and then it could be as it is? >> I could only imagine that it is needed when someone performs some >> other trick in separate process, which includes some 3rd party >> libraries, but currently it is a overkill it seems. >> >> Maybe, just maybe, there should be a require "rubygems" in the >> commands, because we can't assume that everyone has set a -rubygems as >> as RUBYOPT. Because this statement is currently missing then this >> might also be a potential place which causes problems when >> click_no_wait is used. Just a thought. So like this: >> >> def eval_in_spawned_process(command) >> command.strip! >> ruby_code = "require 'rubygems';" >> ruby_code = "require 'watir/ie';" >> ruby_code << "pc = #{attach_command};" # pc = page container >> ruby_code << "pc.instance_eval(#{command.inspect})" >> exec_string = "start rubyw -e #{ruby_code.gsub('"','\'').inspect}" >> system(exec_string) >> end >> >> Also, when simplifying this method as above, we could also delete >> other (rather ugly) method (with it's comment), which is used only >> once: >> >> # why won't this work when placed in the module (where it properly >> belongs) >> def _code_that_copies_readonly_array(array, name) >> "temp = Array.new(#{array.inspect}); #{name}.clear; temp.each >> {|element| #{name} << element}" >> end >> >> What do you guys think about this problem, solutions and >> refactorings/changes? >> >> Jarmo Pertman >> _______________________________________________ >> Wtr-development mailing list >> [email protected] >> http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/wtr-development > _______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
