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

  1. … 21 more files in changeset.
Change CURRENT_VERSION to 4.16.1

More version updates

  1. … 1 more file in changeset.
Update version to 4.16.1

  1. … 20 more files in changeset.
FLEX-35321 CAUSE: if the object isn't on stage when we'd normally set its initialized flag to true, we correctly skip this step, but we also need to set its updateCompletePendingFlag back to false, so that in case it's added to stage again it can work correctly, and have its initialized flag set to true as expected. This second step was skipped in the previous commit. This could be noticed, for example, in DataGrid, which would not show the renderers which it initially used in GridViewLayout.updateTypicalCellSizes(). SOLUTION: set the updateCompletePendingFlag to false even if the object isn't on stage anymore. NOTES: also removed unused imports and an unused local variable.

FLEX-35321 CAUSE: If a component is removed from stage during a validation cycle, the LayoutManager nevertheless sets its initialized flag to true, even if it's not on stage anymore. That's because it doesn't check at the end whether the component is still on stage.

SOLUTION: Now the LayoutManager verifies that the component is still on stage before initializing it.

FLEX-35321 Made the unit test more realistic (by having the user's action happen in the next frame), and prevented an error when tearDown() tries to remove a component which is no longer on stage.

  1. … 1 more file in changeset.
Merge branch 'release4.16.0'

FLEX-34880 Added an asdoc recommendation that developers use Sort and SortField as immutable objects, although the current API allows for mutability.

  1. … 2 more files in changeset.
Revert FLEX-34880 part 3

This reverts commit 2b09e327281211d26d65dd5d061b02d645cbdd39.

  1. … 8 more files in changeset.
Revert FLEX-34880 part 1 This reverts commit 0b5a634dabb00c04a492a08375e29c6885c1486f.

  1. … 9 more files in changeset.
FLEX-34811 allow apostrophe in user name part of email address

FLEX-34880 Placed the other ISortField setters behind mx_internal and removed them from the interface.

  1. … 9 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. … 8 more files in changeset.
fix as docs issue with mismatched tags

fix issues found by Falcon's resolver. Unlike MXMLC, Falcon will always choose the local variable even if it masks a static or instance method. MXMLC seems to resolve to the static or instance method

  1. … 4 more files in changeset.
FLEX-31948 Removing the fatal by checking whether the column exists. Plus some minor code changes while reading code: simplifying if clauses, removing superfluous brackets, adding semicolons.

  1. … 5 more files in changeset.
FLEX-35043 PROBLEM: The assumptions in SF_ORIG_list_events_tester.List_events_collectionKind_move made obvious another problem caused by FLEX-34885: calling itemUpdated(item) did not reposition the item according to the sorting rules (unless the Sort had a customCompareFunction).

CAUSE: FLEX-34885 assumed that the initial logic of checking for ! was to detect when entire objects were replaced with others in the collection. However, it was also detecting when the developer signalled that something (undefined) about an object had changed, and they wanted the sorting / filtering to be reapplied.

SOLUTION: now we call moveItemInView() also when is null and there are no oldValue or newValue specified in the CollectionEvent.


-also updated ListCollectionView_PropertyChangeEvent_Tests and added a new function for objects which are not bindable. As expected, there is a failure without this change to ListCollectionView, and with the change all unit tests pass.

-made explicit a conversion from Object into Boolean in a call to moveItemInView().

-reformated event instantiations to be on one line.

-made some minor changes to SF_ORIG_ListBasic.mxml, which is used by SF_ORIG_list_events_tester.

    • -11
    • +9
  1. … 2 more files in changeset.
FLEX-26808 Added unit tests to make sure that the selection (made either programmatically or through ctrl-clicking on the grid) is preserved when the user starts dragging the items. The tests pass locally.

-Also added VectorUtil.toArrayObject() to convert a Vector.<Object> to an Array (uses the same private function as VectorUtil.toArrayInt(), so I haven't added unit tests).

-Added a missing semicolon in

  1. … 2 more files in changeset.
FLEX-35042 correct minor issue in docs

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.

  1. … 1 more file in changeset.
FLEX-26808 Renamed getFirstItemValue to getFirstItem.

  1. … 2 more files in changeset.
FLEX-26808 Simplified getFirstItemValue using the ternary operator.

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

    • -0
    • +33
  1. … 2 more files in changeset.
FLEX-34852 Mentioning that the spark version of ComplexSortField is preferable.

Revert "TFC-12136"

This reverts commit 45e61644e6a3543937a0fa3db11c3b98b228ae2d.

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.


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


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

    • -18
    • +10
  1. … 1 more file in changeset.
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.