EEZ Studio File Dialog Cancellation: Do Not Treat seqout as a New File Selection

Cancelling a file dialog is a completed interaction, but it is not a new file selection. In the pinned EEZ Studio Dashboard actions, that distinction is visible in the outputs: an ordinary cancellation still reaches seqout while file_path is emitted only for a non-cancelled result.

This matters when a report writer or file loader has retained a path from an earlier interaction. If seqout alone starts the operation, pressing Cancel can leave that earlier value available to the consumer. The diagram can look connected correctly while the operation uses yesterday's selection.

The FileOpenDialog reference and FileSaveDialog reference describe the path outputs. The cancellation details below come from file.tsx at EEZ Studio v0.29.0, commit 3000161d09d40a5c1dc2477ddc30b38037b3a612. This is a source-based wiring review, not an executed dialog test.

Read the conditional and the following statement together

FileOpenDialog awaits the system dialog and derives a path from the first returned filePaths entry. FileSaveDialog obtains its single filePath result. Both normalize Windows-style backslashes to forward slashes before considering output propagation.

Each action then checks result.canceled. Inside the non-cancelled branch it emits file_path. After that branch, it calls propagateValueThroughSeqout and ends asynchronous execution. The continuation is therefore outside the condition that establishes a new selection.

Neither inspected cancellation branch emits an empty string or a null path to replace a previous selection. Absence of an emission is different from emission of a value representing cancellation. A Flow variable or retained data input elsewhere can consequently still contain its old value; the dialog does not clear that storage for the application.

Keep selection-dependent work on the selection path

Treat file_path as the evidence that this interaction produced a selected path. Arrange the downstream read or write so it requires that current emission, rather than using seqout to consume whatever path happens to be stored.

There are several possible application arrangements, but their event ordering must be explicit. One approach gives the selection result its own processing branch and uses ordinary continuation only for returning the interface to an idle state. Another wraps the dialog in an application action that tracks selected versus cancelled outcomes and only releases a selected path to the file operation.

Avoid a shared path variable that means both “last file used” and “new file selected.” Those are useful but different pieces of state. The first may legitimately survive cancellation so the UI can display recent activity. It should not automatically authorize a new write.

Do not assume that a successful save-path choice proves a file was written. FileSaveDialog supplies a path; actual writing is a later operation with its own error and completion behavior. The cancellation boundary is worth fixing before diagnosing filesystem permissions or serialization failures.

A two-interaction fixture exposes stale-path use

Use a harmless temporary location and replace the actual writer with a diagnostic sink. Start with no selected path. Accept the first dialog using a recognizable filename, then invoke the dialog again and cancel it.

Record three observations separately: each file_path emission, each seqout occurrence and each attempted downstream file operation. Under the inspected implementation, the second interaction should produce continuation without a replacement path emission. The diagnostic sink must show no selection-dependent operation for that cancelled interaction.

Repeat cancellation as the very first interaction. That case can reveal a different defect: an absent path, rather than a stale valid one, reaches the consumer. Also repeat an accepted selection after cancellation to confirm the guard has not permanently disabled the operation.

The fixture does not need to write a real report to test the routing. It needs to prove that the operation is tied to the accepted selection from the correct interaction.

Preserve the meaning of cancellation in the interface

A status such as “dialog closed” can follow seqout. A status such as “report saved” cannot be justified by that output alone. Keep messages aligned with the milestone actually observed: selection accepted, write started and write completed are different events.

These conclusions are limited to the pinned Dashboard source. Recheck the installed version if its dialog outputs differ. The durable design decision is simple: cancellation should finish the selection interaction without quietly reusing an older path for a new file operation.