Bret,
The current method is quite a bit different than the method that I
wrote, and I'm not sure it will be as flexible. (For example, you can't
attach to a Frame the way you can to an IE or Modal window.) My method
is designed to completely re-create the exact method string to get back
to the element to be clicked, and is working well for me right now,
though there are some inconsistencies with table related elements (which
is what got me looking at our current container/collection issue).
Right. The method in trunk handles click_no_wait in all watir objects except frames. It is impervious to how we've implemented support for most controls and therefore is unaffected by the issues you've raised with table elements. To my thinking, that makes this code more flexible than what is in the modal_dialog branch. We just need to add support for frames. It's probably just two lines of code. I guess i can do it if you are uncomfortable with this approach.
It's at https://svn.openqa.org/svn/watir/branches/modal_dialog/watir and
I'm doing lots of click_no_wait's from within frames. Feel free to
contact me if you have questions about the code in that branch as it's
pretty much my branch right now and it's probably a dead end until it's
decided to port that code to the current trunk.
What do we have in there that isn't already in trunk, other than the frame/click_no_wait support?
Bret
_______________________________________________ Wtr-general mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-general
