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
