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
