EEZ Studio Regexp: Drive Next Explicitly and Know When a Search Restarts

A Dashboard Regexp action is a stateful search, not necessarily an operation that emits every match at once. If a Flow keeps seeing the first match, inspect which input it drives after processing that match. Re-entering seqin starts a search again; next requests progress through the existing search.

The Regexp documentation describes the start, next and stop controls. The pinned regexp.tsx implementation supplies the state-machine details used here. The version scope is EEZ Studio v0.29.0 editor commit 3000161d09d40a5c1dc2477ddc30b38037b3a612.

Keep the first diagnostic on string input. The same component also accepts a readable stream, but that path introduces buffering and stream lifecycle behavior that a short string fixture does not test.

The first entry already searches

For a new string search, the implementation constructs a RegexpExecutionStateForString. Its constructor immediately calls getNext, so starting the search can produce the first match without a separate next pulse.

After that match, a consumer should decide whether it needs another one. Sending next advances the existing search state. Sending seqin again resets execution state and begins a new search using the configured input and pattern. A visually neat wire looping from “match processed” back to seqin can therefore create repeated first matches rather than a complete traversal.

Use distinct names for the two controls in an operator-facing diagnostic: start search and next match. A single button labeled scan can hide whether the Flow is restarting or advancing.

The global flag changes the continuation contract

The string state uses a RegExp object and its search cursor. When a match is emitted and the expression is not global, the implementation marks its local done flag. A later request enters the completion branch instead of returning another ordinary match from that search.

With global matching enabled, the cursor can advance to later matches. When next exhausts an already-established search, that call emits done and clears the component execution state. Do not infer that enabling global causes the action to push an unbounded list immediately: the component still exposes the next control for requesting further results.

This distinction is easy to demonstrate with two visibly different matches in one short string. A sample containing only one match cannot establish whether the global setting and next route are correct. It also cannot reveal a restart loop that keeps returning the same position.

Observe the match index as well as the matched text. Repeated text can occur legitimately at multiple positions. Comparing only the text might misclassify correct progress as repetition, while observing only a changing application counter might hide an unchanged search position.

Done and stop need a deliberate destination

The string-state stop method emits done and clears its execution state. A next call that exhausts an established search also emits done. If the product needs to distinguish “all matches consumed” from “operator stopped early,” the application needs to retain that reason rather than infer it from the shared output alone.

There is a separate first-entry boundary in this pinned source. The constructor performs its initial getNext before the outer setComponentExecutionState call stores the new object. If the very first search finds no match, getNext emits done and clears state, but the outer call then stores that newly constructed object again. A subsequent next can therefore emit done a second time and clear the stored state. This source-derived ordering is not evidence of two matches or two completed application jobs. Include an initially unmatched string when checking whether the application treats done as a once-only event.

A request to advance without an active search is a different situation from ordinary exhaustion. Test that route through the installed component's error handling instead of relying on a particular silent no-op. Disable or redirect the diagnostic next control when there is no active search if that matches the product's interaction model.

Do not use the completion signal as proof that downstream processing of every emitted match has finished. That depends on how the consumer is wired and whether it starts asynchronous work. The search state owns match traversal; the application owns any separate work queue.

Include one zero-width case

A pattern can match an empty position rather than consuming visible characters. The inspected string implementation checks whether the match index equals the RegExp cursor and increments lastIndex in that case. That guard is specifically intended to prevent repeatedly returning the same zero-width position.

Include a small zero-width diagnostic only after ordinary matching works. Record the emitted positions and the completion condition. Do not translate those positions into byte offsets without checking the JavaScript string and encoding semantics relevant to the consumer. Nor should a simple ASCII fixture be presented as proof of every Unicode boundary case.

The pattern, flags and input form a single search configuration. Preserve them together when reporting a result; otherwise two traces may describe different searches while appearing to expose a runtime inconsistency.

A compact traversal trace

For a two-match string, record start, first match, next, second match, next and done. Then start again to confirm the intended restart behavior. Repeat with global disabled and with an explicit stop after the first match.

No Regexp action was executed for this article. The source-derived distinction is sufficient to guide the wiring review: seqin establishes a new search, next advances an active one, and done reports a traversal outcome whose initial-no-match boundary requires separate handling. Keeping those responsibilities separate is more useful than assuming every outgoing sequence wire means “continue the same scan.”