mirror of
https://git.vladimir.cc/vladimir/ewsdr.git
synced 2026-08-25 20:37:33 +00:00
e09bc21bbaa04ebf1256295dad05abbe881e14d1
Active-VFO desync (batch 15 follow-up): DoConnectDevice loaded FActiveVfo from settings but never re-rendered the highlight (it was drawn once in FormCreate while the field was still 0) nor re-tuned the receiver. Result on reconnect with B last-active: the engine (spectrum, filter band, mouse tuning) ran on VFO B while the UI showed A active. Now the connect path brings both the receiver and the highlight to the actually-active VFO via SetActiveVfo, and RestoreBand's final retune follows the active VFO (A -> ApplyVfoA, B -> SetVfoB) instead of always A. Bandstack on VFO switch: switching the active VFO to one parked on a different ham band now restores that band's DSP state (mode/filter/AGC/ CTUN/FM). Extracted ApplyBandDSP (the DSP half of RestoreBand, without the VFO frequencies) and reused it from both RestoreBand and SetActiveVfo. VFO frequencies stay independent (each VFO carries its own band); continuous tuning across a band edge still does not recall (band button only) as on real radios. SaveCurrentBand no longer writes a VFO frequency into a band's memory unless that VFO is actually within the band, so a 40m VFO-A no longer pollutes 30m's stored VfoA. Per-transverter VFO-B: TXvtrEntry gains LastFreqB (load/save/default + range clamp). ActivateXvtrBand restores VFO B, Deactivate/SaveAllAndExit persist it, and SetVfoB clamps to the transverter range like SetVfoA. The connect-time guard that forced VFO A in XVTR is dropped since B is now a valid, in-range frequency there too. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…
…
…
Languages
Pascal
96.4%
Python
2.9%
Shell
0.6%