ericek111/Nonemm
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Write down what starts the transmit pane again

Browse Source 
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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PdAYHcdRktqKry7nk414TU
This commit is contained in:
ericek111
2026-09-03 14:46:37 +00:00
parent f49a8c10fd
commit 0fc8d7e405
1 changed files with 28 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
docs/unfinished.md
View File

@@ -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 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 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 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 `{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 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 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 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 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 out on the next function key.
empty handler to `OnPttEvent` and takes the transmit state from MMTTY's window
message 32772 instead, which the bridge does not forward yet. 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 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 through `DigitalEngineSender.Transmit`, so the order to key is always the first