Start the transmit pane again on every new message
The macro buttons went wrong at the end of a transmission, both faults in
DigitalEngineSender:
- The engine reports the transmitter drop on its own thread.
WhenTransmitChanged took the state lock, decided the message had ended,
released the lock, and only then called Buffer.Ended(), which clears
what has gone to the engine. A macro pressed on the last character got
through StartAsync in that gap and had already flushed its own text into
Sent, so Ended() wiped the new text off the pane while the engine
transmitted it. Ended() is now called inside the same lock.
- The pane only started again when the engine reported a drop. Two macros
in a row keep the transmitter up, so that report never came and Sent
grew with every press. Everything in Sent is locked, because it is in
the engine and cannot be taken back, so the whole pane became
read-only. TypeAhead.Started() drops the last message's sent text and
keeps what was typed ahead, and StartAsync calls it whenever it keys a
new transmission.
The rest of this commit is the digital transmit work these fixes sit on:
the pane as one coloured box, the sender's three keying states, the
type-ahead feeder paced by the clock with the engine's count as a brake,
{RX} flushing what is left in one piece, and the entry window's function
keys reading the digital macros on a digital mode.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PdAYHcdRktqKry7nk414TU
This commit is contained in:
@@ -7,7 +7,11 @@ namespace Nonemm.Digital;
|
||||
/// N1MM's: the engine is given a title, the PTT port out of Mmtty.INI and a
|
||||
/// command line, and an engine that fails to initialise is started again up to
|
||||
/// ten times, which is what N1MM's retry does.
|
||||
public sealed class MmttyEngine : DigitalEngine
|
||||
///
|
||||
/// It holds a buffer of its own and says how much of it is left, so the
|
||||
/// type-ahead feeds it one character at a time the way N1MM does and paces on
|
||||
/// the count.
|
||||
public sealed class MmttyEngine : DigitalEngine, EngineBuffer
|
||||
{
|
||||
private const int StartAttempts = 10;
|
||||
|
||||
@@ -91,6 +95,12 @@ public sealed class MmttyEngine : DigitalEngine
|
||||
public Task AbortAsync(CancellationToken cancellation = default) =>
|
||||
bridge.SendAsync(BridgeLine.Write("ptt", "0"), cancellation);
|
||||
|
||||
/// The control's `PTT` property back to false, which is the key the other
|
||||
/// way rather than a stop. N1MM never does this: it keys with the property
|
||||
/// and leaves `SetMmttyPTT(1)` to drop the transmitter.
|
||||
public Task ReleaseKeyAsync(CancellationToken cancellation = default) =>
|
||||
bridge.SendAsync(BridgeLine.Write("key", "0"), cancellation);
|
||||
|
||||
/// N1MM's `{TX}` and `{RX}`. Keying is the control's `PTT` property;
|
||||
/// unkeying is `SetMmttyPTT(1)`, which waits for the buffer to empty first,
|
||||
/// so a macro that ends with `{RX}` still goes out in full.
|
||||
@@ -99,6 +109,9 @@ public sealed class MmttyEngine : DigitalEngine
|
||||
on ? BridgeLine.Write("key", "1") : BridgeLine.Write("ptt", "1"),
|
||||
cancellation);
|
||||
|
||||
public Task KeyAsync(CancellationToken cancellation = default) =>
|
||||
SetPttAsync(true, cancellation);
|
||||
|
||||
public Task ReturnToReceiveAsync(CancellationToken cancellation = default) =>
|
||||
SetPttAsync(false, cancellation);
|
||||
|
||||
|
||||
Reference in New Issue
Block a user