From 01c93d979f49dd80926d20781ede1ae62f0dd842 Mon Sep 17 00:00:00 2001 From: rouggy Date: Wed, 29 Jul 2026 12:55:26 +0200 Subject: [PATCH] fix: the Yaesu keyer selection was thrown away when read back MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Choosing "Yaesu (rig keyer)" saved correctly and still produced a WinKeyer panel asking for a COM port. The engine is normalised on load through a chain that names icom, flex and serial and maps EVERYTHING ELSE to "winkeyer" — so the value came back as WinKeyer on every read, whatever the settings said. That is why the panel offered COM3 then COM10: it genuinely believed the engine was a WinKeyer. The list now names yaesu too. The same shape of bug is worth watching for: a normaliser with a silent default turns an unknown value into a plausible one instead of an error, and the symptom appears far from the cause — here, in a panel three components away from the setting. --- frontend/src/App.tsx | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/frontend/src/App.tsx b/frontend/src/App.tsx index a0158f7..81a8f57 100644 --- a/frontend/src/App.tsx +++ b/frontend/src/App.tsx @@ -2421,7 +2421,16 @@ export default function App() { setWkEscClears(s.esc_clears_call !== false); setWkSendOnType(!!s.send_on_type); setWkEsm(!!s.esm); - setWkEngine(s.engine === 'icom' ? 'icom' : s.engine === 'flex' ? 'flex' : s.engine === 'serial' ? 'serial' : 'winkeyer'); + // Every engine has to be named here. Anything unlisted silently became + // "winkeyer", so choosing the Yaesu keyer in the settings still gave a + // WinKeyer panel asking for a COM port — the setting was saved correctly, + // it just never survived being read back. + setWkEngine( + s.engine === 'icom' ? 'icom' + : s.engine === 'flex' ? 'flex' + : s.engine === 'yaesu' ? 'yaesu' + : s.engine === 'serial' ? 'serial' + : 'winkeyer'); } catch { /* keyer not configured */ } }, []);