From 0fc8d7e405e2e1ed71b07e86cd31fdaf7d883103 Mon Sep 17 00:00:00 2001 From: ericek111 Date: Thu, 3 Sep 2026 14:46:37 +0000 Subject: [PATCH] Write down what starts the transmit pane again Two things do, not one: the engine reporting the drop, and a new message being keyed. The second was missing from the text, which is the fault the last commit fixed. The claim that the bridge does not forward MMTTY's window message 32772 is dropped. `docs/digital-bridge.md` argues the control cannot raise `OnTranslateMessage` for a message it has an event for, `OnPttEvent` does report drops here, and the two files disagreed. Says what is known and what is not instead. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01PdAYHcdRktqKry7nk414TU --- docs/unfinished.md | 32 ++++++++++++++++++++++++++++---- 1 file changed, 28 insertions(+), 4 deletions(-) diff --git a/docs/unfinished.md b/docs/unfinished.md index d8de345..0110d3e 100644 --- a/docs/unfinished.md +++ b/docs/unfinished.md @@ -71,7 +71,8 @@ typed into it, and a function key pressed meanwhile goes on the end of what is already waiting. Enter is a new line in the message. The message ends when the transmitter has been told to drop and the engine says it has: what went out is cleared off the pane, what was typed ahead is kept, and nothing goes out again -until TX is pressed. +until TX is pressed. A new message clears the pane the same way, for the case +where two of them run close enough together that the transmitter never drops. `{RX}` runs when the message it stands in has been handed over, wherever it stands in the macro. Every other action macro runs before the text unless it @@ -304,9 +305,32 @@ ignored. MMTTY reports the transmitter down at other times — the buffer hands it one character at a time and keeps it nearly empty — and taking that as the end cleared the pane and shut the gate two or three characters into a message, leaving the rest of it to go -out on the next function key. N1MM does not read that report at all: it binds an -empty handler to `OnPttEvent` and takes the transmit state from MMTTY's window -message 32772 instead, which the bridge does not forward yet. +out on the next function key. + +That report is not the only thing that starts the pane again, because it does +not always come. Two macros pressed one after the other keep the transmitter up +from the first to the last character, so the engine never reports a drop between +them, and the pane kept both messages. Everything the engine has been given is +locked — it cannot be taken back — so a run of macros left a pane with nothing +in it that could be edited. `DigitalEngineSender.StartAsync` now calls +`TypeAhead.Started` whenever it keys a new transmission, which drops the last +message off the pane and keeps whatever was typed ahead. + +`TypeAhead.Ended` is called while the state lock is held, for the same reason. +The drop arrives from the engine on a thread of its own, and a macro pressed on +the last character of a message got as far as handing its own text over in the +gap between reading the state and clearing the pane: the new text was wiped off +the pane while the engine transmitted it. The order was found by reading the +code, not on the air, and the fix has not been tested against a real engine. + +Which of the control's two paths carries the transmit state has not been +settled. The bridge takes it from `OnPttEvent`, and N1MM's `DigitalInterface` +binds an empty handler there and reads MMTTY's window message 32772 out of +`OnTranslateMessage` instead. Both are in the same class, so one of them is a +leftover, and `docs/digital-bridge.md` argues 32772 cannot reach +`OnTranslateMessage` at all while the control has an event for it. `OnPttEvent` +does report drops here, so nothing is missing; it is worth measuring only if the +reports turn out to be coarser than the message. Keying is the keyer's, not the window's: `{TX}` and the TX button both go through `DigitalEngineSender.Transmit`, so the order to key is always the first