On Oct 20, 7:19 am, RJ <[email protected]> wrote: > fire_event('onchange') did not help
I think we might need to see a larger sample of the page HTML in order to have a better idea of what is going on, or if you can share a public URL with this or a highly similar control on it? ---- Background (for those readers new to HTML/HTTP stuff, skip if you already know all this stuff) Typically in basic HTML select lists are part of a form, where the value chosen is submitted via a HTTP POST request when the form as a whole is submitted, usually via a 'submit' button of some variety. Up until the form is submitted, the only changes you see to the page are the values you enter into fields, or choices made on select lists, radio buttons, etc. This is oldschool basic web, pretty much almost pre 'web1.0'. The next advancement over that was forms that would do a 'postback' as each field was changed and get a new version of the page with modified values etc. Or where client side code would execute to alter things based on the choices made, or verify inputs as conforming to some kind of limitation. Both techniques are most often driven by having some kind of 'onchange=xxx' defined for the field. It's usually pretty easy to figure these ones out because the event being looked for is obvious in the HTML of the page itself. This is the stuff we think of as web 1.0.. There's more going on, more use of client side code, but still pretty much the only interaction with the webserver is as entire pages are submitted or requested back. Those tactics were however cumbersome, requiring reloading of entire pages, often with a lot of fields, or depending on client side code for security which left you open to spoofing. In the Web 2.0 world those methods have been replaced with page elements which interact with the server on a more atomic level, JQuery and many other 3rd party tools work this way. They react to changes in fields, sometimes even something as small as a mouseover. In response the code will make changes to states of objects, or their classes (which can then drive other actions via CSS) and often make a 'under the covers' call back to the server with a small amount of specific data, and make changes to a small portion of the page based on the server response, all without reloading the entire page. Figuring this kind of stuff out can be a lot tricker as a lot of the 'wiring' as it were for what events cause what actions are not obvious on the page source itself, and may end up being buried inside javascript, CSS, or other resource files pulled from the server as the page loads. This is where having full access to everything that goes into the page is very useful, or for someone assisting you, being able to access a page with a similar control on it, so we can poke and prod and figure out what makes it tick. The number of ways these kinds of controls can be implemented is pretty varied, and no matter what tool you are using, coming up with a reliable non-brittle script to drive them ends up requiring the scripter to gain a pretty good understanding of the mechanics of the control and how it works. Some of this you can get with resources like the developer tools in chrome, IE, or the firebug plugin for firefox, using that tool to observe the page contents, and notice changes to the DOM in relationship to the actions the user it taking. Part of what makes this tricky is there can often be multiple objects stacked on top of one another, and finding which ones are looking for which events is tricky -- Before posting, please read http://watir.com/support. In short: search before you ask, be nice. [email protected] http://groups.google.com/group/watir-general [email protected]
