Is it possible to pull the text contents out of JavaScript popups as well? That would be a big bonus, particularly on pages that might use a lot of them for different reasons and you want to be sure the right one popped up, or to validate the contents of them. I found SilkTest, one JavaScript popup wasn't distinguishable from another.
Getting them handled well though would be a great start. Thanks; -Jonathan > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bret > Pettichord > Sent: August 17, 2005 5:59 PM > To: [email protected] > Subject: RE: [Wtr-general] next steps > > I wanna hear from the WET guys on this. Satti? Raghu? > > There are two parts of the problem. > 1. Just click the buttons and working the controls. WET has > this licked. > 2. Avoiding the thread-locking. WET uses a method similar to > our IE#remote_eval. But i have ideas on how to make this better. > > Bret > > At 05:36 PM 8/17/2005, Jonathan Kohl wrote: > > > 4. rip out winclicker and autoit and use wet/winobjects > > > instead > >+100 > >We need a good solution for modal dialog boxes, alerts, popups, etc. > >This is the feature I get asked about most frequently (even just a > >couple of hours ago). > > > >-Jonathan > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Bret > > > Pettichord > > > Sent: August 17, 2005 4:32 PM > > > To: [email protected] > > > Subject: [Wtr-general] next steps > > > > > > 1. finish purging all camelCase names in methods and local and > > > instance variables. > > > 2. finish renaming stuff that has the wrong name (like all the > > > references to containers called 'ieController') 3. > > > separate logic for locating objects (get_object) so it can be > > > configured separately without having to what the WET people did > > > (change overriding syntax). > > > 4. rip out winclicker and autoit and use wet/winobjects > instead 5. > > > make it so that anything that be a container; refactor different > > > methods currently used for this (frames & forms) > > > > > > and then > > > > > > 6. defer invokation of COM calls until necessary > > > > > > I've been pushing us this way for a while and believe that it is > > > more important than ever. The simplest example of what > this means > > > is that code like this will work: > > > > > > table = ie.frame(:name, 'foo').table(:index, 4) > > > # do stuff > > > table[3][4].button(:index, 1).click > > > > > > This is convenient and often what casual users expect. > > > Currently watir supports this to one level only. > > > > > > Once we have this, this gives us a platform that we can > do several > > > other > > > things: > > > a. invoke method in a separate process, so we never run > into thread > > > blocking problems again. > > > b. invoke selenium or xcom/mozilla or another browser-driving > > > technology instead of IE/COM c. attach a logger so we get cheap, > > > decent, accurate logging > > > > > > > > > > > > _____________________ > > > Bret Pettichord > > > www.pettichord.com > > > > > > _______________________________________________ > > > Wtr-general mailing list > > > [email protected] > > > http://rubyforge.org/mailman/listinfo/wtr-general > > > > > > >_______________________________________________ > >Wtr-general mailing list > >[email protected] > >http://rubyforge.org/mailman/listinfo/wtr-general > > _____________________ > Bret Pettichord > www.pettichord.com > > _______________________________________________ > Wtr-general mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/wtr-general > _______________________________________________ Wtr-general mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-general
