EEZ Studio Counter: Account for the Entry That Emits done

With Count value set to three, an EEZ Studio Counter can emit three ordinary continuations and still require another entry before it emits done. That detail matters when the counter sits in a feedback loop or is used to count completion events. “Three body passes” and “done has fired” are different observations.

The Counter documentation describes its ordinary and done outputs. In the pinned framework implementation, the first execution initializes internal count. An execution that sees a positive count decrements it and takes seqout. An execution that sees a nonpositive count frees the state and takes done.

This source analysis uses framework commit dc9af2d5004201d6c31273a4c4fcfe27fc20c234, separately from the EEZ Studio v0.29.0 editor reference. Verify the project's runtime; the conclusions are not a claim about every historical or Flow Lite implementation.

Write the entry sequence, not just the count

For Count value = 3, the first entry changes the internal count from 3 to 2 and emits seqout. The second changes 2 to 1 and emits seqout. The third changes 1 to 0 and still emits seqout. The fourth sees zero and emits done.

This trace is a source-derived expectation, not a recorded execution. It explains why wiring only three external pulses into the Counter does not establish that done will be observed. The last decrement and the done branch occur on different entries.

For Count value = 0, the first execution takes done without an ordinary body pass in the inspected implementation. Use a nonnegative integer count for the basic diagnostic. Do not rely on an accidental negative or poorly converted value to represent a separate control mode.

A feedback loop must supply the next entry

When Counter is used to repeat work, connect the body-completion path so it re-enters Counter after each completed pass. That return after the final body pass is what allows the Counter to observe zero and take done.

If the body has an early exit that bypasses the return, the repetition stops at that point without necessarily producing done. Decide whether that is intended cancellation, an error outcome or a wiring defect. Do not display “completed” merely because no further body activity is visible.

Use a harmless body that increments a diagnostic variable before integrating real work. Count ordinary output pulses, body completions and done pulses separately. Their relationship should be explicit, especially if a body can fail or finish asynchronously.

Count value is an initialization input for the cycle

The inspected code evaluates Count value when it allocates Counter execution state. Later entries use the stored integer. Changing the variable behind Count value in the middle of that active cycle does not establish a new live limit in this implementation.

That can be useful when a batch should keep its original size despite later UI edits. It can also surprise a design that expects changing a numeric field to shorten the current cycle. Define whether the edit applies to the current request or the next one, and communicate that policy in the UI.

After the done path frees the state, a later new entry initializes a new count. Therefore a stray late pulse can start a fresh cycle. Identify the sources that can still reach the Counter after completion rather than treating done as a permanent disabled state.

Do not mistake the component for an asynchronous barrier

Suppose three independent jobs run in parallel and each reports completion to the Counter. A count alone does not verify that the three pulses came from three distinct jobs. A duplicate completion can consume an entry, while a missing completion can leave the expected sequence unfinished.

The extra entry needed for done also makes this usage different from a barrier that fires immediately on the Nth unique completion. If the product needs that contract, maintain explicit request identities and completion state in an appropriate application design. Do not silently redefine Counter's observed entry semantics to fit it.

Even in a serialized loop, connect the return at the true completion point. Returning after merely submitting an asynchronous operation counts submissions, not completed operations. That may be valid, but it is a different measurement and should be named accordingly.

Use a small regression matrix

Test counts zero, one and three. For each, record every input entry, ordinary continuation and done output. Then change the Count value expression during an active cycle and observe which cycle uses the new value. Finally, deliver a deliberate additional entry after done in a diagnostic environment.

These cases reveal initialization, decrement, completion and reinitialization without a long-running batch. They also make late or duplicate input paths visible before the Counter is connected to expensive operations.

No Flow run was performed here. The key acceptance question is not only whether the body executes the desired number of times. It is whether the graph supplies the completion-detecting entry, handles every exit deliberately and prevents unrelated late pulses from silently beginning another cycle.