flex-sdk

Clone Tools
  • last updated 29 mins ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
FLEX-35046 changed icon to be font weight normal

FLEX-35056 Fix RTE when pressing escape

FLEX-26808 Adding VectorUtil.toArrayInt() to convert a Vector to an Array (and a few unit tests for it). This is useful for the unit testing we're doing for this ticket.

FLEX-34837 As noticed in FLEX-26808, if the dimensions are not specified the grid layout will not render its GridViews. Test still passes.

FLEX-26808 Adding unit test. For now we're just testing that Ctrl+Click deselects the (selected) first item (test passes). Dragging behaviour will follow.

FLEX-26808 Minor refactoring while reading the code: asdocs improvements, and adding missing semicolon.

FLEX-26808 Added VectorUtil to manifest.

FLEX-26808 Optimizing imports.

FLEX-26808 Terminating statements, correcting asdocs, and removing an unused variable and unused method.

FLEX-26808 CAUSE: DataGrid.grid_mouseDownHandler() committed the selection before checking whether the user was likely to begin a drag operation.

SOLUTION: Following the pattern in the spark List component, we're committing the selection on MOUSE_DOWN only if the user has clicked on an item which isn't selected yet, or the grid is not dragEnabled, or we're not in row selection mode (i.e. either GridSelectionMode.SINGLE_ROW or GridSelectionMode.MULTIPLE_ROWS). But when it looks like the user might start a dragOperation, we're deferring the selection adjustment to the MOUSE_UP event (caught either in DataGrid.grid_mouseUpHandler() or in DataGrid.sandbox_mouseUpHandler() ).

NOTES:

-also removed some duplication between DataGrid.grid_mouseDownHandler() and DataGrid.removeMouseHandlersForDragStart().

-also corrected some asdocs @see references.

FLEX-26808 Improved asdocs and comment.

FLEX-26808 Renamed getFirstItemValue to getFirstItem.

FLEX-26808 Simplified getFirstItemValue using the ternary operator.

FLEX-26808 Moving Vector-related function List.getFirstItemValue() to new VectorUtil class (unit tested in VectorUtilTests.as)

FLEX-34852 Mentioning that the spark version of ComplexSortField is preferable.

Revert "TFC-12136"

This reverts commit 45e61644e6a3543937a0fa3db11c3b98b228ae2d.

FLEX-35039 Ignoring failing tests until we decide to work on this bug. Also renamed the functions to point to the relevant ticket.

TFC-12136 Removing all the PropertyChangeEvent dispatches which have no value set for property and oldValue, and the itemUpdated() calls in collections (which yield the same type of events) when they come after updates to object's public and bindable properties, because that makes the dispatches superfluous. (The ones I'm leaving in are the ones after updating private properties on objects, so after bypassing the bindable getters and setters, e.g. in AbstractEmployeeTimeAllocationGroupTO; and the ones I don't have time to understand why they're there.)

As a result, IMulticurrencyLineItem does not need to extend IEventDispatcher anymore.

NOTES:

-see the comment in this ticket for why it should be pretty safe to do this.

-also made some minor refactoring where appropriate.

FLEX-35043 Updating unit tests to reflect new behaviour.

FLEX-35043 CAUSE: The solution implemented for FLEX-34885, which had an problematic consequence: when calling itemUpdated(item) on a collection with only the first parameter provided (which developers usually do to signal that some - unspecified - properties of the item have changed), ListCollectionView.handlePropertyChangeEvents() would treat that as if the object had been just introduced to the collection - as "property" was null -, replacing a null value - since oldValue was null as well. (That is to say, when the "property" value of the PropertyChangeEvent was null, it was taken to mean that the oldValue - which was also null here - was changed into that item, i.e. the object reference changed in the collection, not just one of the object's properties.) As such, it would try to remove that supposedly existing null value from the collection (and sometimes a null does exist, but shouldn't be removed).

In a way this was logical based on the properties supplied to itemUpdated(), but we also know that a frequent use of that function is with only one parameter, to specify that some of the object's properties have changed (but the object itself should still be in the collection). So we should continue to support this use case.

SOLUTION: now ListCollectionView.handlePropertyChangeEvents() only assumes that the entire object has been replaced in the collection if the event's "property" is null AND if either its "oldValue" or "newValue" is non-null. In other words, if the developer entered all these arguments into the function or in the event they're dispatching, and one of them is non-null, it probably means they want to signal that the entire object has changed in the collection.

NOTES:

-renamed "entireObjectChanged" into "objectReplacedWithAnother" to emphasize that it's not the object's internal state that "entirely changed", but that the object itself was replaced in the collection by another object instance.

-some of the unit tests in ListCollectionView_PropertyChangeEvent_Tests are now failing, which is expected.

FLEX-34885 Tagging which unit tests are relevant to FLEX-35043.

FLEX-34885 Adding unit tests to show that IList/ICollectionView.itemUpdated() creates the same unexpected results as dispatching generic PropertyChangeEvents from list items.

FLEX-34885 Making sure that the changes for this ticket haven't introduced the bug of removing a null from the collection when an item's Bindable property changes. Looks all right.

FLEX-34885 Added a unit test to make sure that object is re-run through the collection filter when any of its properties changes.

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.

NOTES:

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

NOTES:

-also removed some whitespace and improved asdocs.