EEZ Studio SortArray: Consume the Returned Array and Test Equal Keys

An EEZ Studio SortArray action can produce a correctly sorted result while the list on screen stays in its original order. The first thing to inspect is which array the list consumes. SortArray returns a result; treating it as an in-place mutation can leave the UI bound to the unchanged input.

The SortArray documentation describes sorting without modifying the supplied array. The pinned framework implementation clones the input, sorts that clone with qsort and emits the resulting array.

The implementation reference is framework commit dc9af2d5004201d6c31273a4c4fcfe27fc20c234. It was inspected separately from EEZ Studio v0.29.0; verify the actual runtime in the project before applying code-level details. This analysis concerns standard EEZ Flow.

Follow the returned value all the way to the consumer

Start with a small integer array whose order is visibly different from the desired result. Send it through SortArray, and inspect the input and result independently. Then connect or assign the result to the state consumed by the list.

Keep the two names distinct during diagnosis, such as sourceItems and sortedItems. Reusing one name for every stage can hide the fact that the display still reads the original reference. Once the flow is understood, the application can deliberately replace its current list with the returned result if that matches its ownership model.

The clone operation supports the observed separate-result behavior, but this function alone does not establish a deep-copy contract for every nested value. Do not use it as proof that subsequently mutating a nested object in one array can never affect another reference. That is a separate value-ownership question.

Equal keys need an explicit policy

A sorted order can satisfy the primary comparison while arranging equal-key records differently from the order the product expects. The cited implementation uses qsort; it does not establish a stable-order guarantee for equal keys.

Build a test array with records that have distinct identities but the same chosen sort key. Observe their identities before and after sorting. Do not test only unique values, because unique keys cannot reveal whether the application is accidentally relying on tie preservation.

If the product requires a deterministic secondary order, define that requirement explicitly and choose a supported implementation that can enforce it. The SortArray interface and selected runtime must be checked before assuming an arbitrary multi-key comparator is available. A requirement for stable ties is not satisfied by repeatedly running one convenient example and seeing the same order.

Numeric conversion can matter at the edges

The inspected comparator converts numeric values through toDouble but stores those converted values in local float variables before comparing their difference. The local declaration, not the suggestive variable name, determines the intermediate representation.

That is a reason to test large, closely spaced numbers and values near the precision limits relevant to the target. Do not promise exact ordering of every integer identifier or double-valued measurement merely because the source array accepts that type. Values distinguishable in one representation can become indistinguishable in a narrower comparison path.

Use real bounds from the product. If values are small counters, the precision concern may be irrelevant. If they are large timestamps or identifiers, a rounded comparison could affect the required order. This article reports no failed numeric test; it identifies a source-level conversion that deserves a targeted check.

Strings and structure fields have their own cases

For strings, test the case-sensitive or case-insensitive mode actually selected. Include equal strings and strings that differ only in case if those occur in the product. Do not infer a complete locale-aware collation policy from an ignore-case option.

For structures, verify the configured array type and field used for comparison. A plausible order can be produced from the wrong field, especially if a copied action retained an earlier configuration. Choose a diagnostic set where ordering by the intended field differs clearly from ordering by another field.

Keep invalid input tests separate from ordinary ordering tests. The implementation includes type checks, but a malformed structure or conversion failure should not be treated as an ordinary tie without examining the selected path. The acceptance case should use well-formed data first, then explore the failures the application can actually receive.

Accept the ordering contract, not just a pretty list

A compact regression set includes an empty array, one item, unique values, duplicate keys and the relevant numeric or string boundary. Record the returned result and the array the UI ultimately consumes. For records, preserve identities in the diagnostic output so equal-key behavior is visible.

The final decision should state whether ties may reorder, which numeric range is supported and whether the source array remains available for another purpose. These are application contracts, not details to infer from a screenshot after one sort.

No sorting experiment or UI run was performed here. The proposed checks address three separate risks: ignoring the returned array, relying on undocumented tie stability and overlooking the comparator's actual intermediate representation.