That's what I'm thinking, since majority of modal test cases work for me in 1.8.7 ...
Cheers, Tim On Mon, Jan 17, 2011 at 3:52 PM, Jarmo <jarm...@gmail.com> wrote: > I was wondering, do you even have to recompile it for different Ruby > versions, which have same minor version number? At least i have understood > that you only need to recompile binaries if the major or minor version > number differ. E.g. you can use same binary for 1.8.6 and 1.8.7, but need to > recompile it for 1.9.1 and 1.9.2. Am i wrong? > > Jarmo > > > On Mon, Jan 17, 2011 at 12:55 AM, Bret Pettichord <b...@pettichord.com>wrote: > >> On Thu, Jan 13, 2011 at 9:07 PM, Tim Koopmans <tim.ko...@gmail.com>wrote: >> >>> When you say Win32OLE is patched/hacked, is that the shared object in >>> C:\ruby187\lib\ruby\1.8\i386-mingw32 >>> or >>> C:\ruby187\lib\ruby\gems\1.8\gems\watir-1.7.0\lib\watir\win32ole.rb OR >>> win32ole\win32ole.so ? >>> >> >> win32ole.so is compiled from win32ole.c, which has been hacked. >> https://github.com/bret/watir/tree/master/watir/lib/watir/win32ole >> >> >>> If win32ole is the only thing holding us back, why don't we crack on with >>> the ming compiled version and ditch 1.8.6 altogether? >>> >> >> We also need to make sure that there are no baseline changes to win32ole. >> If so, then we would need to migrate the patch to the new version of >> win32ole before recompiling. >> >> If we do this we could release the result as 1.8.0. We would need to >> update the minor version number as it would change the Ruby requirement, no >> longer supporting what we had required previously. While we are at it, maybe >> would should pull in some other big changes, like the zero-index code. >> >> As long as we depend on the current approach (hack and recompile >> win32ole), we will have a tight binding between Watir (or at least this part >> of Watir) and the version of Ruby we've compiled for. The question is >> whether we want remove this technical debt. >> >> If we swap out the wrong version of win32ole, it might cause Watir tests >> to fail. It could also cause other code using win32ole to fail. We don't >> have tests for the latter case. >> >> Bret >> >> >> On Tue, Jan 11, 2011 at 1:39 PM, Bret Pettichord <b...@pettichord.com>wrote: >> >>> Charley's comment and a discussion with Hugh McGowan at work have >>> reminded me of the state of this. >>> >>> 1. We actually swap in our own copy of the Ruby Win32OLE library. This is >>> C code and therefore needs to be compiled using the same compiler as Ruby. >>> The version currently distributed with watir works with early versions of >>> 1.8.6. I think they changed to the new compiler (ming) in the most recent >>> versions of 1.8.6. >>> >>> 2. This whole approach is incredibly hacky (it was my idea). I have >>> previously suggested that we pull this code (the showModalDialog support >>> only) into a separate gem simply because it does these horrible things and >>> adds these dependencies that really don't matter to many Watir users. >>> >>> 3. I was a bit confused, because I know we have some people using 1.8.7 >>> at Convio, but apparently this is because Hugh hacked the version of >>> Win32Ole to make it work. >>> >>> 4. Yes, Jarmo that is "the" modal dialog test. >>> >>> Bret >>> >>> On Mon, Jan 10, 2011 at 11:54 AM, Jarmo <jarm...@gmail.com> wrote: >>> >>>> On Mon, Jan 10, 2011 at 5:39 PM, Tim Koopmans <tim.ko...@gmail.com>wrote: >>>> >>>>> I've recommended 1.8.6 or 1.8.7 of Ruby but thinking of cutting this >>>>> back to 1.8.7, pending IE modal dialog support (is there a specific unit >>>>> test for that?) >>>>> >>>> >>>> I found something at unittests\windows\modal_dialog_test.rb. I'm not >>>> sure if that is THE modal dialog, but it seems to be. For me that test >>>> blocks forever under Win7/XP with 1.8.6 and 1.8.7. Haven't had any time to >>>> investigate as to why is that happening. Maybe someone else can try that >>>> test on their machine too to see if there's any difference and maybe even >>>> figure out the problem itself. >>>> >>>> Jarmo >>>> >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development@rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>> >>> >>> >>> >>> -- >>> Bret Pettichord >>> Director, Watir Project, www.watir.com >>> >>> Blog, www.testingwithvision.com >>> Twitter, www.twitter.com/bpettichord >>> >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> >> >> -- >> Bret Pettichord >> Director, Watir Project, www.watir.com >> >> Blog, www.testingwithvision.com >> Twitter, www.twitter.com/bpettichord >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development@rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development@rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development >
_______________________________________________ Wtr-development mailing list Wtr-development@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-development