Clone Tools
  • last updated 19 mins ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Update nightly build to 4.17.0

  1. … 22 more files in changeset.
Update version to 4.16.1

  1. … 20 more files in changeset.
FLEX-27509 CAUSE: In an AdvancedDataGrid with non-text item renderers AdvancedDataGrid.expandItem() applies masks onto those item renderers when it needs to close a node. At the same time, AdvancedListBase has its own custom mechanism for using masks to scroll vertically in a more efficient way. In order to detect whether it's used this mechanism, and reset the changes (detection happens in AdvancedListBase.removeClipMask(), while the mechanism is applied in addClipMask()), it simply asks whether the non-text item renderer has a mask applied. However, this mask could have been applied by the expandItem() mechanism mentioned above, which means that addClipMask() will never have been called. As a result, itemMaskFreeList is still null, which leads to the fatal.

SOLUTION: Ideally there should be a flag that specifies whether AdvancedListBase.addClipMask() has applied the masking mechanism. But for now we can simply check that itemMaskFreeList isn't null before we use it.

FLEX-27509 CAUSE: In an AdvancedDataGrid with non-text item renderers AdvancedDataGrid.expandItem() applies masks onto those item renderers when it needs to close a node. At the same time, AdvancedListBase has its own custom mechanism for using masks to scroll vertically in a more efficient way. In order to detect whether it's used this mechanism, and reset the changes (detection happens in AdvancedListBase.removeClipMask(), while the mechanism is applied in addClipMask()), it simply asks whether the non-text item renderer has a mask applied. However, this mask could have been applied by the expandItem() mechanism mentioned above, which means that addClipMask() will never have been called. As a result, itemMaskFreeList is still null, which leads to the fatal.

SOLUTION: Ideally there should be a flag that specifies whether AdvancedListBase.addClipMask() has applied the masking mechanism. But for now we can simply check that itemMaskFreeList isn't null before we use it.

Revert FLEX-34880 part 3

This reverts commit 2b09e327281211d26d65dd5d061b02d645cbdd39.

    • -1
    • +1
    ./mx/collections/GroupingCollection.as
    • -1
    • +1
    ./mx/collections/GroupingCollection2.as
  1. … 7 more files in changeset.
FLEX-34880 Placed only one state setter (SortField.compareFunction) behind mx_internal (thus also renaming it to SortField.compareFunction_) to provide the template for the others. Also removed it from the interface (ISortField).

    • -1
    • +1
    ./mx/collections/GroupingCollection.as
    • -1
    • +1
    ./mx/collections/GroupingCollection2.as
  1. … 7 more files in changeset.
FLEX-35126 Removing unused variables, making elligible functions static, correcting an asdoc typo, and removing superfluous multiplication by 1.

  1. … 3 more files in changeset.
FLEX-31948 Same changes for AdvancedDataGridBaseEx as for DataGrid.

    • -1
    • +2
    ./mx/controls/AdvancedDataGridBaseEx.as
FLEX-35031 Making sure that extra asdoc information is included by placing the @inheritDoc tag after the extra comments, as explained in http://help.adobe.com/en_US/flex/using/WSd0ded3821e0d52fe1e63e3d11c2f44bc36-7ff6.htm ("You can add content to the comment before the @inheritDoc tag.")

FLEX-35031 FLEX-33058 -Simplified algorithm in findAny() and findLast(). -Improved asdoc for these functions. Note that all tests still pass.

  1. … 1 more file in changeset.
FLEX-35031 FLEX-33058 -Moved the valuesAreSubsetOfObject() function in ObjectUtil and added some unit tests for it. -Instead of iterating through the object's properties using a String object in ObjectUtil.getEnumerableProperties(), we are now using an Object instance. In this way, int properties will not be converted to String anymore.

  1. … 2 more files in changeset.
FLEX-35031 FLEX-33058 Clarifying intent by renaming function and changing the order of its parameters.

FLEX-35031 FLEX-33058 CAUSE: -FLEX-33058: HierarchicalCollectionViewCursor assumed, in findAny() and findLast(), that all the items in the collection will have all the properties that the parameter does. That seems like a safe assumption to make when findAny() is called with current as the parameter (as it is in collectionChangeHandler()), but even that isn't always true, as the example in the ticket demonstrates: when the HierarchicalCollectionViewCursor works on a HierarchicalCollectionView with a GroupingCollection2 as its source, some of the objects it will traverse will be the anonymous objects created by GroupingCollection2 to represent the groups (which have the "mx_internal_uid" property seen in the RTE, and also "children" and "GroupLabel"), and others will be the grouped items, which are often sealed class instances which we can't expect to have those properties.

-FLEX-35031: The (other) assumption in findAny() and findLast() was that the parameter was NOT a sealed class instance. Its properties were being inspected using a regular for(var i:String in values) loop, which only yields anything if values's properties are enumerable, i.e. are defined on a dynamic object. So when 'values' was a sealed class instance (as often happens in collectionChangeHandler(), where the parameter is current, which is often a sealed class instance), the algorithm incorrectly assumed that there was no difference between 'values' and 'current', because 'values' seemed to have no properties at all.

SOLUTION:

Now we assume we have a match if and only if the objects are the same, or if the parameter is dynamic and 'current' shares all its properties and values (even if it contains other properties and values, it's still a match).

NOTE:

-the solution implies, as documented in the unit tests, that findAny({}) and findLast({}) will return the first and, respectively, the last item in the collection. This seems to be how it should work.

-we're now using non-strict equality checks, which implies, again as documented in the unit tests, that searching by the string equivalent of a number property will still work.

  1. … 1 more file in changeset.
FLEX-35031 Just noticed that findLast uses the same algorithm as findAny, so I added a unit test which reproduces the bug there as well, and renamed some of the local variables in a similar way to the recent findAny() renames. -Also added unit tests to make sure that searching via partial objects works.

  1. … 1 more file in changeset.
FLEX-33058 Minor refactoring while reading codeȘ -simplified if statements -corrected asdocs -optimized imports -removed unused variables

  1. … 3 more files in changeset.
FLEX-33058 Renaming some variables to clarify intent and increase readability.

    • -2
    • +0
    ./mx/collections/GroupingCollection2.as
FLEX-33058 Minor refactoring while reading the code: -removing unused variables -improving comments and asdocs -terminating statements

    • -15
    • +9
    ./mx/controls/AdvancedDataGridBaseEx.as
update version to 4.16.0

  1. … 19 more files in changeset.
FLEX-34879 Replacing SortField setters with constructor arguments.

    • -8
    • +3
    ./mx/controls/AdvancedDataGridBaseEx.as
  1. … 3 more files in changeset.
FLEX-32249 Now AdvancedDataGrid.makeListData() uses the HierarchicalCollectionViewCursor through its IHierarchicalCollectionViewCursor interface, so that other cursors can be used which don't extend HierarchicalCollectionViewCursor.

    • -84
    • +84
    ./mx/controls/AdvancedDataGrid.as
FLEX-34775 CAUSE: Asking the HierarchicalCollectionView to open an inaccessible node (e.g. a node whose parent is closed) would succeed (but should not). A consequence was that HierarchicalCollectionView.length was incremented (say, by 1 if that node had no children), which is wrong: the collection length hadn't changed (because the newly opened node cannot be accessed due to its closed parent), since the collection length represents the number of nodes that can be accessed by navigating it via a cursor. Then navigating this HierarchicalCollectionView via a cursor would enter an infinite loop because HierarchicalCollectionViewCursor.afterLast uses the HierarchicalCollectionView.length property to know when it reached the last node. However, if the length property is higher than reality, the cursor will think it never reaches the last node (because HierarchicalCollectionViewCursor.moveNext() will simply do nothing when it's at the end of the collection, which is true when HierarchicalCollectionViewCursor.current is null; see HierarchicalCollectionViewCursor.moveNext).

SOLUTION: We don't allow the opening of an inaccessible node anymore.

NOTES:

-this solution is verified by HierarchicalCollectionView_FLEX_34775_Tests.

-as part of this change I also removed unused variables and corrected some comments in HierarchicalCollectionView.

FLEX-34778 CAUSE: When a node is opened, HierarchicalCollectionView starts to listen to changes to its children collection. And when it's closed, it doesn't stop listening to these CollectionEvents. So when a closed node's child is replaced, nestedCollectionChangeHandler is triggered, even if the node itself is closed. Part of nestedCollectionChangeHandler's function is to dispatch a REMOVE CollectionEvent for all the nodes which were removed by the replacement (which is, all the descendants of the replaced - but closed! - node). Then, since the node that's being replaced is not accessible anymore (because its parent was closed), it's not added to convertedEvent.items. But the next lines assume that the replaced node will be in that array without mistake. Otherwise (as it happens in this bus) it goes into an infinite loop trying to find it.

SOLUTION: instead of looking for the node with an (indefinitely) incrementing index, we're now using Array.indexOf() to locate the node and remove it if it's found.

FLEX-34778 CAUSE: When a node is opened, HierarchicalCollectionView starts to listen to changes to its children collection. And when it's closed, it doesn't stop listening to these CollectionEvents. So when a closed node's child is replaced, nestedCollectionChangeHandler is triggered, even if the node itself is closed. Part of nestedCollectionChangeHandler's function is to dispatch a REMOVE CollectionEvent for all the nodes which were removed by the replacement (which is, all the descendants of the replaced - but closed! - node). Then, since the node that's being replaced is not accessible anymore (because its parent was closed), it's not added to convertedEvent.items. But the next lines assume that the replaced node will be in that array without mistake. Otherwise (as it happens in this bus) it goes into an infinite loop trying to find it.

SOLUTION: instead of looking for the node with an (indefinitely) incrementing index, we're now using Array.indexOf() to locate the node and remove it if it's found.

Update version to 4.14.1

Signed-off-by: Erik de Bruin <erik@ixsoftware.nl>

  1. … 22 more files in changeset.
Revert "Merge commit '1884960242f835879f5ca6504659072a2305f120' into release4.14.0"

This reverts commit 7a051584552d332fc27e743b6ef83864a0737e53, reversing

changes made to 1884960242f835879f5ca6504659072a2305f120.

  1. … 45 more files in changeset.
Update version to 4.15.0

Signed-off-by: Erik de Bruin <erik@ixsoftware.nl>

  1. … 22 more files in changeset.
FLEX-32541 Removing unused constant.

FLEX-32541 CAUSE: AdvancedDataGridHeaderRenderer.mouseEventToHeaderPart() assumes that sortItemRendererInstance cannot be null. However, as the project attached to the ticket shows, it can.

SOLUTION:

When sortItemRendererInstance is null, we return AdvancedDataGrid.HEADER_TEXT_PART, as there is no icon.

switch version to 4.14

  1. … 23 more files in changeset.
FLEX-34458 CAUSE: Because HierarchicalCollectionViewCursor uses both relative and absolute bookmarks in the various collections of the hierarchy, there needs to be special treatment for these two cases. Namely, while it works great with absolute bookmarks to call .movePrevious on the bookmark when something is deleted in the same collection before the selected item, it doesn't work well for the relative CursorBookmark.LAST currentChildBookmark value. Because HierarchicalCollectionViewCursor.collectionChangeHandler() did not make any difference between absolute and relative bookmarks, it used to call .movePrevious() on the bookmark even if it was the absolute value CursorBookmark.LAST.

SOLUTION:

In this situation we don't need to .movePrevious() when items above are deleted, because CursorBookmark.LAST will always point to the last item in the collection, no matter what changes happened to that collection.