EEZ Studio Dashboard Terminal Echo: Avoid Feeding One Keystroke Back Twice

A character appearing twice in an EEZ Studio Dashboard Terminal does not by itself prove that a command was transmitted twice. The widget can render the typed character locally and then render a peer's echo through its incoming Data path.

The Terminal reference describes string or stream input and the onData event. The pinned implementation shows the two rendering routes, at EEZ Studio v0.29.0 commit 3000161d09d40a5c1dc2477ddc30b38037b3a612.

The discussion concerns this Dashboard Terminal widget. It does not assume that an instrument terminal, a serial driver or a remote shell has identical echo behavior.

Typing already writes to the terminal

When creating its xterm instance, the component registers an onData callback. That callback first calls terminal.write with the received input data. It then executes the EEZ widget's onData action when a Flow state is available.

Consequently, connecting onData to a transport is not the first route by which the typed text reaches the display. The local write has already been attempted. A peer can receive one input sequence while the screen later shows that sequence twice.

The incoming side is separate. The widget accepts string data for display, and it also attaches a data listener to a stream whose chunks are converted to strings and forwarded to the terminal's display callback. Routing a peer's echoed input into either incoming path creates another rendering opportunity.

Isolate rendering from transmission

A useful proposed fixture starts without a real process or instrument. Type a printable character such as A and record the onData payload without returning it to Data. The inspected source predicts the local display write and one outgoing event path.

Next, supply an incoming B through the widget's Data input without typing it. This isolates the receive-render path. Finally, use a small in-memory echo mock that returns the onData payload once through Data. One typed A now has two display paths: its local write and the returned echo.

Record the outgoing event count, returned payload count and terminal appearance separately. If the outgoing count is one and the returned count is one, a doubled display is consistent with echo topology. If the outgoing count is already two, investigate that separately; the local rendering explanation does not account for duplicate transmissions.

This fixture has not been executed here. It is deliberately confined to printable characters so that cursor movement, line endings and terminal escape sequences do not obscure the first observation.

Assign echo responsibility at the connection boundary

For an actual peer, identify whether it echoes input and whether that behavior can be configured through its documented interface. A connection that relies on local echo needs a different display arrangement from one that relies on peer echo.

The inspected EEZ callback contains the local write directly. This article does not identify a supported inspector toggle that disables it. Do not invent such a setting or assume an option from another terminal application applies to this widget.

Where the peer supports a suitable echo mode, configure that mode deliberately and verify the combined result. If the application instead needs a different local-render policy, treat it as an integration or source-maintenance change with its own test coverage. Suppressing arbitrary incoming data is not an equivalent repair.

In particular, removing repeated adjacent characters would corrupt legitimate output such as repeated letters, numeric values or progress indicators. A text comparison cannot reliably determine whether a matching character is an echo or independent peer output.

Extend the test only after the basic routes are clear

After establishing the printable-character case, examine backspace, Enter and any control sequences required by the intended peer. Local rendering and peer-side line editing can interact in ways that a single-character fixture cannot predict.

Keep transport diagnostics independent from terminal appearance. A readable screen is not a record of exactly what bytes were transmitted, and a doubled screen is not proof of two writes to the peer. The source-backed lesson is the presence of two rendering routes; tracing those routes first prevents an echo symptom from being mistaken for a command-delivery failure.