[
https://issues.apache.org/jira/browse/PIVOT-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Brown resolved PIVOT-548.
------------------------------
Resolution: Fixed
Resolved for TreeView.
> Fire selection change events when selection changes indirectly
> --------------------------------------------------------------
>
> Key: PIVOT-548
> URL: https://issues.apache.org/jira/browse/PIVOT-548
> Project: Pivot
> Issue Type: Improvement
> Components: wtk
> Reporter: Greg Brown
> Assignee: Todd Volkert
> Fix For: 2.0
>
>
> Currently, selection change events are fired only when an explicit call has
> been made that affects the selection. For example, in ListView, calling
> either setSelectedRanges() or clearSelection() will fire this event. However,
> an operation that indirectly changes the selection state (such as adding or
> removing an item from the ListView's model data) does not trigger an event.
> This was originally done by design - selectedRangesChanged() includes the
> previous selection as an argument, and we didn't want to have to manually
> re-construct that every time the selection changed as a side effect of a
> model change:
> public void selectedRangesChanged(ListView listView, Sequence<Span>
> previousSelectedRanges);
> However, in practice, working within this model can be challenging. More than
> once I have registered a selection change listener expecting to receive
> notification of all selection changes, forgetting that it is not designed
> that way. I'm guessing that other developers may be confused by this as well.
> So, I am proposing that components that maintain a selection state also fire
> selection change events when the selection changes indirectly. In this case,
> a null value would be passed for the previous selection. This will save the
> effort of re-constructing the previous selection info and will give the
> listener additional information about the nature of the change (i.e. null ==
> indirect state change).
> This change should also be propagated to TextInput, which has a similar issue
> with character change events. Currently, TextInput fires character change
> events via TextInputCharacterListener and text change events via
> TextInputTextListener. The textChanged() event does not pass the previous
> text value, which is inconsistent with other change events. textChanged()
> should be incorporated into TextInputCharacterListener and should pass the
> previous text value when it is changed via an explicit call to setText();
> otherwise, it should pass null.
> The updated version of TextArea should probably follow the same approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
