EEZ Studio SwitchCase: Separate Case Matching from Sequence Continuation

EEZ Studio SwitchCase has two questions to answer: which case, if any, matched, and whether the action continues through its sequential output. Treating those as the same question can make an unmatched value look like a successful classification, or make a continuation path run before branch-specific work has actually finished.

The SwitchCase documentation describes ordered tests and selection of the first true case. The pinned framework implementation breaks after that match, then propagates seqout after the case loop. A no-match traversal also reaches that final call when evaluation completed without an error.

This analysis is scoped to framework commit dc9af2d5004201d6c31273a4c4fcfe27fc20c234 and standard EEZ Flow. The EEZ Studio editor reference is v0.29.0; its use does not prove that a particular exported project contains this exact framework revision.

First-match order is part of the design

Consider two conditions: “temperature exceeds the warning threshold” and “temperature exceeds the critical threshold.” A critical value can satisfy both. If the warning test appears first, first-match selection can choose it before the critical test is considered.

Make overlapping conditions intentional. Put a more specific condition first when that matches the required priority, or define mutually exclusive ranges. Do not rely on the visual placement of downstream components to repair the order of the tests configured inside SwitchCase.

A useful review example contains one value that satisfies only the first test, one that satisfies only another test and one that satisfies both. The overlapping case proves the priority rule. Testing only isolated ranges can leave an incorrect order undiscovered until a boundary value appears in use.

No match and evaluation failure are different outcomes

For a no-match input, the inspected code produces no selected case output but still reaches the separate seqout call. That can be useful for general continuation after classification. It is not proof that the input belonged to an accepted category.

An expression failure follows a different path. The function returns early if evaluating a condition fails, converting it to Boolean fails, or evaluating the selected output value fails. Therefore “seqout always fires” would be incorrect. The precise source-derived statement is that ordinary case-loop completion reaches seqout, including ordinary no-match completion.

If the product requires explicit handling of unknown inputs, add a deliberate fallback design. A final always-true condition may be appropriate where supported and correctly configured, but give that output a clear meaning such as “unrecognized input.” Do not route it into the same success handling as a valid category unless that is genuinely the product rule.

Continuation does not mean the selected work finished

The code propagates the selected case value and then seqout. That describes propagation calls within SwitchCase, not a completion barrier for whatever the selected branch starts. A case branch might begin asynchronous work or enqueue several later actions.

If a common final step must run after branch-specific work finishes, route explicit completion from that work to the final step. Do not place the final step on SwitchCase seqout merely because it appears visually below the branch diagram.

For example, selecting a file category and starting a load operation are different milestones. A general “classification attempted” continuation can occur after the switch decision. A “file is loaded” continuation needs evidence from the load operation itself. Naming these milestones accurately makes incorrect wiring easier to see.

Instrument outputs independently

Create a diagnostic project with harmless sinks. Give each case output its own counter and payload log. Give seqout a separate counter. Avoid using the same visual label for both observations, because one update can conceal another.

Run a small matrix:

1. Exactly one condition matches: identify the selected output and the separate continuation.
2. Two conditions match: verify that only the first configured match is selected.
3. No condition matches: distinguish no selected output from seqout continuation.
4. A deliberately supported runtime error is injected: inspect the configured error handling rather than expecting ordinary continuation.

The error case must use a failure mechanism known to the selected runtime. An editor-rejected expression is not a runtime-error experiment. Keep the diagnostic free of real device commands so an incorrect route cannot cause an unintended operation.

Keep output values as deliberate data

Each selected case supplies its configured value. Check that value as well as which connector fired. Two branches can select correctly yet send an unexpected payload, especially when a copied condition still refers to another category's value expression.

If downstream code needs to distinguish matched and unmatched inputs, carry that distinction explicitly in the branch design or application state. A generic sequential pulse alone is insufficient evidence of a valid classification.

No Flow execution was performed here. The proposed matrix tests a concrete SwitchCase contract: ordered first-match selection, separately observed continuation and separately handled evaluation errors. That is more precise than treating the component as a single undifferentiated branch that either “runs” or “stops.”