OK, great. Thanks. On Wed, Aug 31, 2011 at 4:41 PM, Jarmo <[email protected]> wrote:
> No, and i already fixed the problem. Read about it in the thread > http://groups.google.com/group/watir-general/browse_thread/thread/9d5557820580249e > > Jarmo > > > On Wed, Aug 31, 2011 at 11:02 PM, Bret Pettichord <[email protected]>wrote: > >> I just read the original thread. >> >> Seems like this code is in question. >> >> def assert_exists >> locate if respond_to?(:locate) >> >> unless ole_object >> raise UnknownObjectException.new( >> Watir::Exception.message_for_unable_to_locate(@how, >> @what)) >> end >> >> Would changing it to this fix the performance problem? >> >> def assert_exists >> unless ole_object >> locate if respond_to?(:locate) >> end >> unless ole_object >> raise UnknownObjectException.new( >> Watir::Exception.message_for_unable_to_locate(@how, >> @what)) >> end >> >> >> >> On Mon, Aug 29, 2011 at 1:33 AM, Jarmo <[email protected]> wrote: >> >>> I've already answered to that problem in the original thread at >>> http://groups.google.com/group/watir-general/browse_thread/thread/9d5557820580249e >>> >>> I've also added some suggestions along the line of the same points as >>> Ethan brought up. >>> >>> Jarmo >>> >>> >>> On Sun, Aug 28, 2011 at 11:46 PM, Ethan <[email protected]> wrote: >>> >>>> I don't know why you're using class variables here. that's just wrong to >>>> begin with. >>>> it looks like this basically bypasses relocating in most circumstances. >>>> this makes assert_exists do pretty much nothing. >>>> that's fine in many circumstances, but it'll fail when things start >>>> modifying the dom with javascript. the ole object will become invalid, and >>>> should be relocated, but this bypasses that. >>>> watir should be doing two things, I've found: be better about only >>>> checking if an element needs relocating when operations have been performed >>>> which may have modified the dom; and check if the ole object is in fact >>>> still attached to the dom before trying to relocate. >>>> >>>> On Fri, Aug 26, 2011 at 10:31, Michalski Jerzy >>>> <[email protected]>wrote: >>>> >>>>> >>>>> Following Zeljko's suggestion, I resume here the problem I presented in >>>>> "Watir is slow with nested frames" thread of the Watir General group ( >>>>> * >>>>> https://groups.google.com/forum/?pli=1#!topic/watir-general/nVVXggWAJJ4 >>>>> *<https://groups.google.com/forum/?pli=1#!topic/watir-general/nVVXggWAJJ4> >>>>> ). >>>>> >>>>> I use Ruby 1.8.7, Watir 1.9.2, IE8 >>>>> >>>>> Problem: >>>>> When I execute an action on an element placed in a deeply nested frame, >>>>> the method assert_exists from the Element class is called again and >>>>> again by many methods, also by those called by assert_exists! As a result, >>>>> for my simple example of 7 nested frames (see the thread "Watir is >>>>> slow with nested frames" for details), this method was called 1536 >>>>> times! The same elements were located again and again with exactly the >>>>> same >>>>> criteria (@how, @what and @container)! >>>>> >>>>> My solution >>>>> I modified the method assert_exists by adding four class variables that >>>>> store the three location criteria and the OLE object found. Next time when >>>>> the method assert_exists is called, the new criteria are compared with the >>>>> previous ones. If they are the same, no need to 'locate' again, simply >>>>> return the object found previously. After my modification, the method >>>>> assert_exists is called only 17 times (always with my simple example), and >>>>> the real location is done only 8 times (7 frames and one text field) - >>>>> other >>>>> 9 calls return the previously located objects. And everything takes less >>>>> than 1 second (compared to 15 seconds before!). >>>>> >>>>> Here is the modified method: >>>>> >>>>> def assert_exists >>>>> if respond_to?(:locate) >>>>> if (defined?(@@how) && defined?(@@what) && >>>>> defined?(@@container) && defined?(@@o) && >>>>> @@how == @how && @@what == @what && @@container == >>>>> @container) >>>>> # The element has already been located -> take the already >>>>> located OLE object >>>>> @o = @@o >>>>> else >>>>> # Locate the element... >>>>> locate >>>>> # ...and save the information that served to locate it... >>>>> @@how = @how >>>>> @@what = @what >>>>> @@container = @container >>>>> # ...and also the located OLE object. >>>>> @@o = @o >>>>> end >>>>> end >>>>> unless ole_object >>>>> raise UnknownObjectException.new( >>>>> Watir::Exception.message_for_unable_to_locate(@how, >>>>> @what)) >>>>> end >>>>> end >>>>> >>>>> Question: >>>>> As I am new to Watir (and Ruby), maybe I have ommited an important >>>>> functionnality that may be broken by my modification. Is there a downside >>>>> to this? >>>>> >>>>> Jurek >>>>> _Disclaimer >>>>> Vaudoise.ch______________________________________________________________-_ >>>>> Le présent courriel, y compris les pièces jointes, s’adresse >>>>> exclusivement à la (aux) personne(s) ou à la société à laquelle >>>>> (auxquelles) >>>>> il est destiné et peut comporter des informations confidentielles et/ou >>>>> protégées par la loi. Toute divulgation, reproduction ou utilisation de >>>>> ces >>>>> informations est interdite et peut être illégale. Si vous n’êtes pas >>>>> destinataire de ce courriel, merci de le détruire immédiatement et d’en >>>>> aviser l’expéditeur. >>>>> This e-mail, including attachments, is intended for the person(s) or >>>>> company named and may contain confidential and/or legally privileged >>>>> information. Unauthorized disclosure, copying or use of this information >>>>> may >>>>> be unlawful and is prohibited. If you are not the intended recipient, >>>>> please >>>>> delete this message and notify the sender. >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> >> -- >> Bret Pettichord >> Director, Watir Project, www.watir.com >> >> Blog, www.testingwithvision.com >> Twitter, www.twitter.com/bpettichord >> >> >> _______________________________________________ >> 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 > -- Bret Pettichord Director, Watir Project, www.watir.com Blog, www.testingwithvision.com Twitter, www.twitter.com/bpettichord
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
