[ https://issues.apache.org/jira/browse/PIVOT-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Volkert resolved PIVOT-474. -------------------------------- Resolution: Fixed > Ensure that selection is visible in ListView, TableView, etc. > ------------------------------------------------------------- > > Key: PIVOT-474 > URL: https://issues.apache.org/jira/browse/PIVOT-474 > Project: Pivot > Issue Type: Improvement > Components: wtk, wtk-wtkx > Reporter: Greg Brown > Assignee: Todd Volkert > Priority: Minor > Fix For: 1.5 > > Attachments: sample.html > > > In most cases, when a component's selection changes, it should be made > visible via scrollAreaToVisible(). This is currently done when the user > navigates the view via keyboard (e.g. up/down arrows) but it does not happen > when the user changes selection state programmatically. The caller must > manually call scrollAreaToVisible(). > The call to scrollAreaToVisible() can't occur until after the component has > been laid out. This requires knowledge on the caller's part of how the > component is implemented internally. While this may be viewed as a simple > documentation issue, it is compounded by the fact that hidden components are > not laid out until they are made visible. As a result, some fairly complex > code is required to ensure that such components properly reflect selection > state when they are hosted in containers such a CardPane or TabPane, which > manage the visibility of their children. > One solution might be to eliminate the optimization that prevents a component > from being laid out when it is not visible. This would make it easier for a > calling application to know when it is OK to call scrollAreaToVisible(). > However, this is not ideal since the optimization otherwise seems fairly > valid. > Another option is for the skin class to automatically scroll the selection to > visible when the selection changes. When the component is valid, the > scrolling could be performed immediately, but would need to be deferred until > layout() when the component is invalid. This also assumes that we always want > to scroll the selection to visible every time it changes - this seems > reasonable, but are there use cases where we might not want to do this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.