Since the code is correct, this is just a documentation issue. I created
LPP-8388.
Thanks!
Phil
On Wed, Aug 12, 2009 at 3:48 PM , P T Withington wrote:
Surely `onselected` _has_ to be sent every time `selected` is set,
whatever its value. That's the definition of an event for an
attribute.
`onselect`, since it is a stand-alone event, can have a different
contract; but it would seem odd to me to have `onselect` only sent
when `selected` is true without a corresponding `onunselect` event (or
something).
Personally, I would rather _not_ fall down the Perl hole of "there are
47 different ways of doing the same thing". I'd think long and hard
about why you need 3 different events when you can get the same
information from one. [The only parallel I can think of is in <state>
where we have 'onapplied', 'onapply', and 'onremove'.]
On 2009-08-12, at 14:19EDT, Max Carlson wrote:
Perhaps the accessibility code needs to ignore events when selected
== false?
[email protected] wrote:
Hi Max,
I'd like your thoughts on this. I think there is a problem in
baselistitem. If setSelected() is called with false, the onselect
and onselected events are generated.
<method name="setSelected" args="s">
<![CDATA[
this.selected = s;
if (this.onselect.ready)
this.onselect.sendEvent(this);
if (this.onselected.ready)
this.onselected.sendEvent(this);
]]>
</method>
According to the docs:
onselect Event sent when the user makes a selection.
onselected Event sent when this item is selected.
I don't think either of these should be generated if this.selected
is false and this might explain some of the strange behavior in
LPP-7594. I will play with this tomorrow.
Thanks!
Phil
--
Regards,
Max Carlson
OpenLaszlo.org
