On Wed, Nov 09, 2005, Mike Williams wrote:
> Aahz wrote:
>> Mike removed somebody's attribution:
>>>
>>> | check | options cheese | |
>>
>> The main problem I see with this is that "options cheese" is a valid
>> name. Do we currently require that to be in quotes?
>
> Hmmm. No, we neither support
Aahz wrote:
> | check | options cheese | |
The main problem I see with this is that "options cheese" is a valid
name. Do we currently require that to be in quotes?
Hmmm. No, we neither support nor require quotes, right now.
I understand that it might be *technically* valid to have an elem
On Sun, Nov 06, 2005, Mike Williams wrote:
>
> Having started down that road, I'm now wondering whether it mightn't be
> better to simply extend the "name=" locator itself to support an
> optional "element selector" suffix, e.g.
>
> | check | options cheese | |
The main problem I see with t
David Kemp wrote:
I like the idea of extending the locator.
Great.
Should you be able to capture the state of a single check box with:
| storeChecked | options cheese | myVariable |
Can you then use that variable later to set the checked status of
another check box:
| check | options onio
[EMAIL PROTECTED]
wrote on 06/11/2005 12:01:03 AM:
> Therefore, I think we need to find a way to identify a toggle-button
> within a name-group, using a secondary attribute; typically 'value'.
My
> first thought was that this could be done via a second, optional
> argument to the toggle-but
I recently added a couple of commands for dealing with toggle-buttons,
ie. checkboxes and radio-buttons.
check( locator )
uncheck( locator )
assertChecked( locator )
assertNotChecked( locator )
As you can see, they currently just accept a single element-locator
argument.
Now,
: Re: [Selenium-devel] check/uncheck commands
Harman, Elaine wrote:
> Apologies in advance for the long, dull novel.
No problem. Thanks for taking the time.
At present, everything that uses an element-locator expects the return
value to be, well, an element. I don't think we wanna
Harman, Elaine wrote:
Apologies in advance for the long, dull novel.
No problem. Thanks for taking the time.
At present, everything that uses an element-locator expects the return
value to be, well, an element. I don't think we wanna have to check in
each case whether it is in fact an ele
Apologies in advance for the long, dull novel.
> This is not exactly a bug - more a limitation of the design. At the
> moment, element locators are expected to return only a single element.
> This works nicely for most cases, but as you've found, it makes it
> trickier to deal with groups of rad
Harman, Elaine wrote:
Looks like there's a bug in PageBot.locateElementByName, when
retrieving a form array element. e.g.: Option #1 Option #2
This is not exactly a bug - more a limitation of the design. At the
moment, element locators are expected to return only a single element.
This work
10 matches
Mail list logo
