mirror of
https://git.vladimir.cc/vladimir/ewsdr.git
synced 2026-08-25 20:37:33 +00:00
Uladzimir KarpenkaandClaude Opus 4.8
831e5c3a31
ActivateXvtrBand/DeactivateXvtr followed the Band pattern: the state + DSP + network now live on TRadioController; the UI renders via events. - ApplyXvtrToNetwork moved to the controller (XVTR enable bit / DisablePA / RX antenna). MainForm.ApplyXvtrToNetwork is a thin delegate. - ActivateXvtr builds a TBandSettings from the XVTR slot and runs it through the shared ApplyBandDSP (mode/filter/AGC/CTUN/FM), then sets VFO B (range-clamped) / VFO A / center / drive and pushes to the radio. Render is driven by Changed(rfXvtr) + Changed(rfActiveVfo). The slot has no stored filter bandwidth, so FilterBWFor(mode, idx) derives it from the per-mode table without changing the index. - DeactivateXvtr saves the slot via SaveCurrentBand (its XVTR branch already writes the whole slot) and exits; the HF return (RestoreBand + final active-VFO retune) stays in the UI wrapper. - SetXvtrBand is now a real dispatcher (>=0 activate, <0 deactivate). - rfBand render is XVTR-aware (clears HF band buttons while in XVTR); added an rfXvtr render case for the XVTR button highlight. - The thin UI wrappers keep only wideband-view + web push. ~150 lines of inline logic removed from MainForm; all callers (web/channel/band-click/ startup) are unchanged and go through the wrappers. Also fixes a latent filter-restore bug surfaced by the XVTR round-trip (transverter -> HF -> transverter): the rfMode render calls UpdateFilterButtons, which resets the non-FM filter to the mode default. That reset belongs to a mode change (the controller already applies it via ApplyModeDefaults), not to a passive render, so it clobbered the filter restored from the band/XVTR cache. rfMode now preserves FFilter/FFilterBW around UpdateFilterButtons. This also fixes the same loss on plain HF band switches for non-FM modes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>