Fix TX frequency reset when band changes via frequency edit - #1113
Merged
Conversation
Typing a TX frequency that belongs to a different band than the one currently selected (e.g. entering 435 MHz while on 2M) could make the just-typed value silently snap back to the old RX frequency. MainWindow::slotFreqTXChanged() switches the band via mainQSOEntryWidget->setBand() before writing the new frequency to the TX spin box. That band switch re-enters MainWindow::slotBandChanged() synchronously (directly, and again through the satellite tab's band combos), which decides whether to reset the TX frequency to the new band's default by reading the TX spin box's *current* value - still the pre-edit frequency at that point, since the real value hasn't been written yet. That stale read intermittently causes it to conclude the new value is out of band and reset it, discarding what the user typed. Guard the reentrant call with a flag so slotBandChanged() skips that reset whenever the band switch is itself driven by a frequency edit; the correct frequency is already being applied right after by the caller. Manually changing the band combo box directly is unaffected and still resets the frequency to the band's default as before. Also fixes a comma-operator typo in MainWindowSatTab::slotSatBandTXComboBoxChanged() (`if (expr, MHz)`) that made two related band/satellite checks always evaluate true, found while tracing the same reentrant frequency-sync path. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KnQDWAUkEBcsfH2ahuU6kC
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR fixes a bug where the TX frequency would be incorrectly reset when the user edits the TX frequency and the band automatically changes as a side effect.
Key Changes
freqDrivenBandChangeflag to track whenslotBandChanged()is being called as a side effect of a frequency edit inslotFreqTXChanged()slotBandChanged()to skip TX frequency reset when the band change was triggered by a frequency edit, preventing the use of stale frequency valuesmainwindowsattab.cppwhere extra parameters were being passed toisThisFreqInBand()callsImplementation Details
The core issue was a race condition: when
slotFreqTXChanged()callssetBand()to update the band based on the new frequency, this can synchronously re-enterslotBandChanged(). At that point, the TX frequency spinbox still contains the old value, soslotBandChanged()would incorrectly use it to decide whether to reset the TX frequency.The fix uses the
freqDrivenBandChangeflag to signal that the band change is frequency-driven, allowingslotBandChanged()to skip its frequency validation logic and let the correct frequency value be applied by the subsequentsetTXFreq()call inslotFreqTXChanged().https://claude.ai/code/session_01KnQDWAUkEBcsfH2ahuU6kC