flex-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mihai Chira (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FLEX-34119) mx.collections.HierarchicalCollectionViewCursor causes CursorError RTE from ListCollectionView when the underlying collections change
Date Wed, 26 Feb 2014 17:35:19 GMT

     [ https://issues.apache.org/jira/browse/FLEX-34119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mihai Chira updated FLEX-34119:
-------------------------------

    Description: 
Run the attached AIR project. (Avoid debug mode unless you want to press F8 MANY times). It
will take around 10s.

The unit test (HierarchicalCollectionViewCursorTest.as) shows many of the ways in which HierarchicalCollectionViewCursor's
state can make ListCollectionView fail through a seek() operation on ListCollectionViewCursor
by allowing a CursorError to be thrown from ListCollectionView.getBookmarkIndex() (I say 'allowing'
because it could easily prevent it).

The (long) trace output shows all the configurations of the collection-view that I constructed
which cause the RTE.

Notations:
[SEL] - the currently selected item by the HierarchicalCollectionViewCursor (cursor.current).
[INS] - the newly inserted item, which caused the RTE
[REPL] - the item which, when replaced, causes the RTE (notice there's only one such instance
- when the (selected) second stage is replaced with another item).

NOTES:
* for us this has caused numerous, apparently mysterious bugs within AdvancedDataGrids which
boiled down to one or other of these configurations.
* The reproduceCursorErrorWithDisableAutoUpdate() test shows that the error can also be thrown
by not allowing the HierarchicalCollectionView (and, implicitly, the HierarchicalCollectionViewCursor)
to know about changes in the underlying collections (by using disableAutoUpdate() in conjunction
with refresh() and enableAutoUpdate()). We were using these methods to optimise expensive
updates in the collections shown in the AdvancedDataGrids, without realising they had a knock-on
effect on the HierarchicalCollectionView used by the grids. This part of the error-generation
scenario is controlled by the programmers, of course, but it might be worth documenting, so
that others can avoid these issues.
* I found one bug report which hints at these problems, but it doesn't seem to have kept its
attachment: FLEX-33054. The last comment shows the exact part of the code which calls seek(),
thus generating the RTE.

  was:
Run the attached AIR project. (Avoid debug mode unless you want to press F8 MANY times). It
will take around 10s.

The unit test (HierarchicalCollectionViewCursorTest.as) shows many of the ways in which HierarchicalCollectionViewCursor's
state can make ListCollectionView fail through a seek() operation on ListCollectionViewCursor
by allowing a CursorError to be thrown from ListCollectionView.getBookmarkIndex() (I say 'allowing'
because it could easily prevent it).

The (long) trace output shows all the configurations of the model collection-view that I constructed
which cause the RTE.

Notations:
[SEL] - the currently selected item by the HierarchicalCollectionViewCursor (cursor.current).
[INS] - the newly inserted item, which caused the RTE
[REPL] - the item which, when replaced, causes the RTE (notice there's only one such instance
- when the (selected) second stage is replaced with another item).

NOTES:
* for us this has caused numerous, apparently mysterious bugs within AdvancedDataGrids which
boiled down to one or other of these configurations.
* The reproduceCursorErrorWithDisableAutoUpdate() test shows that the error can also be thrown
by not allowing the HierarchicalCollectionView (and, implicitly, the HierarchicalCollectionViewCursor)
to know about changes in the underlying collections (by using disableAutoUpdate() in conjunction
with refresh() and enableAutoUpdate()). We were using these methods to optimise expensive
updates in the collections shown in the AdvancedDataGrids, without realising they had a knock-on
effect on the HierarchicalCollectionView used by the grids. This part of the error-generation
scenario is controlled by the programmers, of course, but it might be worth documenting, so
that others can avoid these issues.
* I found one bug report which hints at these problems, but it doesn't seem to have kept its
attachment: FLEX-33054. The last comment shows the exact part of the code which calls seek(),
thus generating the RTE.


> mx.collections.HierarchicalCollectionViewCursor causes CursorError RTE from ListCollectionView
when the underlying collections change
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: FLEX-34119
>                 URL: https://issues.apache.org/jira/browse/FLEX-34119
>             Project: Apache Flex
>          Issue Type: Bug
>          Components: Advanced Data Grid
>    Affects Versions: Apache Flex 4.11.0
>            Reporter: Mihai Chira
>              Labels: collections, cursors
>             Fix For: Apache Flex 4.12.0
>
>         Attachments: _HierarchicalCollectionViewCursorBug.fxp
>
>
> Run the attached AIR project. (Avoid debug mode unless you want to press F8 MANY times).
It will take around 10s.
> The unit test (HierarchicalCollectionViewCursorTest.as) shows many of the ways in which
HierarchicalCollectionViewCursor's state can make ListCollectionView fail through a seek()
operation on ListCollectionViewCursor by allowing a CursorError to be thrown from ListCollectionView.getBookmarkIndex()
(I say 'allowing' because it could easily prevent it).
> The (long) trace output shows all the configurations of the collection-view that I constructed
which cause the RTE.
> Notations:
> [SEL] - the currently selected item by the HierarchicalCollectionViewCursor (cursor.current).
> [INS] - the newly inserted item, which caused the RTE
> [REPL] - the item which, when replaced, causes the RTE (notice there's only one such
instance - when the (selected) second stage is replaced with another item).
> NOTES:
> * for us this has caused numerous, apparently mysterious bugs within AdvancedDataGrids
which boiled down to one or other of these configurations.
> * The reproduceCursorErrorWithDisableAutoUpdate() test shows that the error can also
be thrown by not allowing the HierarchicalCollectionView (and, implicitly, the HierarchicalCollectionViewCursor)
to know about changes in the underlying collections (by using disableAutoUpdate() in conjunction
with refresh() and enableAutoUpdate()). We were using these methods to optimise expensive
updates in the collections shown in the AdvancedDataGrids, without realising they had a knock-on
effect on the HierarchicalCollectionView used by the grids. This part of the error-generation
scenario is controlled by the programmers, of course, but it might be worth documenting, so
that others can avoid these issues.
> * I found one bug report which hints at these problems, but it doesn't seem to have kept
its attachment: FLEX-33054. The last comment shows the exact part of the code which calls
seek(), thus generating the RTE.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message