Clone Tools
  • last updated 26 mins ago
Constraints: committers
Constraints: files
Constraints: dates
Additional fix for https://issues.apache.org/jira/browse/FLEX-34391 Ensure that StageText's viewport width and height values stay are less than stage.stageWidth and stage.stageHeight

Fix for https://issues.apache.org/jira/browse/FLEX-34391 Ensure that StageText's viewport x/y values stay within the range 0 to stage.stageWidth or stage.stageHeight

FLEX-34885 Adding more checks to make sure that when generic PropertyChangeEvents are dispatched, the objects that dispatch them are not moved to another location in the ListCollectionView.

FLEX-34885 Adding more unit tests to make sure that when generic PropertyChangeEvents are dispatched, bindings are not triggered for the containing object either.

FLEX-34885 The error that ListCollectionView_PropertyChangeEvent_Tests.test_when_collection_item_dispatches_PropertyChangeEvent_sort_compare_function_called_with_null_and_fatals_if_no_null_check() expects is thrown as an uncaught client error, it seems, as opposed to a synchronous error. Now we're handling it so.


-also removed a test added in the wrong place (HierarchicalCollectionViewCursor_FindAny_Tests)

FLEX-34885 Added a new unit test class, ListCollectionView_PropertyChangeEvent_Tests, that not only tests a few scenarios to make sure that ListCollectionView reacts as expected to PropertyChangeEvents, but also makes explicit 2 of the consequences of manually dispatching PropertyChangeEvents through the VOs in the list without specifying a "property" and an "oldValue" in the PropertyChangeEvent: 1. null is assumed to have been replaced in the collection by that VO, so it will be removed if it already exists. This may be unexpected to developers. 2. if there's a customCompareFunction in the Sort object, it will be called with null as one of the arguments. This may again be unexpected to developers.


-also removed some whitespace and improved asdocs.

FLEX-33058 Further increasing the timeout for the test.

FLEX-35037 FLEX-35039 Referenced the newly created ticket number in the failing ArrayCollection tests.

FLEX-35037 Renaming test files to 1) show what they're testing and 2) make sure they're picked up and ran by the test scripts.

  1. … 3 more files in changeset.
FLEX-35037 Renaming ac to _sut ("system under test") and making it private instead of protected.

FLEX-35037 Swapping arguments in asserts, to get better error messages. (No changes in test results.)

FLEX-35037 Adding Apache headers.

FLEX-35037 Fixed the logic of some of the failing tests. The ones that are still failing seem to point to actual bugs.

FLEX-35037 Added unit tests donated by Justin Mclean. Currently some are failing.

FLEX-34885 Testing some assumptions about how bindings work in relation to PropertyChangeEvents, because dispatches of generic PropertyChangeEvents might interfere with assumptions put in for this fix. More unit tests will follow, specifically for interactions with lists.

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 Added more unit tests for ObjectUtil.isDynamicObject() to test that it returns correctly for XML, Proxy and ObjectProxy.

FLEX-33058 Lengthening test's timeout even more.

FLEX-33058 Lengthened the test's timeout.

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

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.

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.


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).


-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.

FLEX-35031 -Added more unit tests for ObjectUtil.getEnumerableProperties. -Added the option of specifying whether strict equality should be used in ArrayUtil.arraysMatch() and ArrayUtil.arrayValuesMatch(), or just a regular equality check.

FLEX-35031 -Since I'm planning to use ObjectUtil.isDynamicObject() in the fix, I wanted to unit test it. -Also, I introduced a new function in ObjectUtil to be used in the solution, getEnumerableProperties(), which returns all the dynamic properties of an object. In order to unit test this new method I needed a function with which to compare Arrays. So I added it to ArrayUtil, including the unit tests needed to validate it. -Also edited an asdoc entry and renamed a function parameter.

    • -0
    • +293
    • -0
    • +167
FLEX-35031 Added two more test functions to assert that dynamic object instances should work the same as anonymous object instances for finding items via HierarchicalCollectionViewCursor. Currently they pass, as expected.

FLEX-35031 Added two more test functions to make explicit the assumption that searching by sealed class instances with a subset of the properties of the object to be found will NOT work (analogous to searching by anonymous objects with a subset of the properties of the target object, which should work, as documented in the same class), at least at the moment. There is no business case for it, and the framework itself doesn't seem to require it. -A couple of other minor changes, like removing unused imports and editing asdocs.

FLEX-35031 Added more unit tests to define how findAny() and findLast() should work, for when I attempt fixes for this bug. -Making sure that they return different values when there are two objects in the collection view with the same property and value for that property (currently they do). -Made the ids unique for the EmployeeVOs, which makes it easier to index them and use them in tests.

FLEX-35031 Added more unit tests to define how findAny() and findLast() should work, for when I attempt fixes for this bug. -By adding more unit tests I also found that null as a parameter to findAny() or findLast() makes the cursor think it's found that value.

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.