[
https://issues.apache.org/jira/browse/FLEX-26143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Mclean updated FLEX-26143:
---------------------------------
Labels: easyfix easytest (was: )
> incorrect datagrid layout with custom vertical scrollbars when scrollbar
> width != 16
> ------------------------------------------------------------------------------------
>
> Key: FLEX-26143
> URL: https://issues.apache.org/jira/browse/FLEX-26143
> Project: Apache Flex
> Issue Type: Bug
> Components: mx: DataGrid
> Affects Versions: Adobe Flex SDK 3.5 (Release)
> Environment: Affected OS(s): All OS Platforms
> Affected OS(s): All OS Platforms
> Browser: Internet Explorer 8.x
> Language Found: English
> Reporter: Adobe JIRA
> Labels: easyfix, easytest
>
> Steps to reproduce:
> 1. create a skin for a vertical scrollbar thumb of width 10
> 2. override 'get measuredWidth' to return 10
> 3. create 10px wide images for arrows, track, and background
> 4. set everything in CSS
> 5. create a test datagrid with 2 columns and enough items to enable scrolling
>
> Actual Results:
>
> Datagrid lays out as if the vertical scrollbar has a width of 16. List
> content is laid out incorrectly, so the textfield contents of column #2 will
> be too far to the left. scrolling the grid, sorting a column, or calling
> invalidateList() on the datagrid will force another layout with the correct
> results.
>
> Expected Results:
>
> Contents are laid out correctly the first time.
>
> Workaround (if any):
>
> Nothing reasonable.
> Explanation:
> The issue is in ScrollControlBase.setScrollBarProperties(). This method is
> invoked recursively in an update display list cycle. In here, a vertical
> scrollbar is created if needed. The problem is that its minWidth is accessed
> (default 16) and used for layout before it has a chance to go through its
> lifecycle and measure (which would result in a minWidth of 10).
> Once the vertical scrollbar does measure, we get back into the update display
> list cycle (and setScrollBarProperties) but there's nothing to indicate that
> the scroll area has changed. We get into ListBase.updateDisplayList(), but
> the short-circuit fires (because the boolean scrollAreaChanged is false) and
> nothing is done.
> In ScrollControlBase.createVScrollBar(), there is a comment wondering if
> validateNow() should be called on the newly created scrollbar. The answer is
> yes, because that would force the measure and the layout would be done
> correctly the first time.
> The other option is to rewrite scroll control base to use the lifecycle
> instead of invoking updateDisplayList() directly and recursively. This would
> allow the measure of the vertical scrollbar and the subsequent invalidations
> to happen naturally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
