Fix HamLib radio type and Enable checkbox reset on settings open

[barjac]

Summary

Two related bugs in the HamLib settings page that cause the saved radio type and the "Enable HamLib" checkbox state to be silently overwritten whenever the user opens the Settings dialog and clicks OK without visiting the HamLib tab.

---

Bug 1: Radio type overwritten with first list entry

What happens

After opening Settings → OK (without visiting the HamLib tab), the saved radio type (e.g. NET rigctl) is replaced with whichever rig appears first in the alphabetically-sorted list.

Root cause

SetupPageHamLib lazy-loads the rig combo box — it is only populated in showEvent() the first time the HamLib tab is shown. However, saveSettings() is called unconditionally on every OK click, and writes:

```cpp
settings.setValue("HamLibRigType",
hamlib->getModelIdFromName(rigTypeComboBox->currentText()));
```

When the combo is empty, currentText() is "". getModelIdFromName("") uses QMap::operator[] on a missing key, which default-constructs to 0. So HamLibRigType=0 is written to config, overwriting the correct saved value.

On the next run, setRigType("0") looks up model ID 0, finds nothing (hamlib models start at 1), and falls back to setCurrentIndex(0) — the first rig alphabetically.

When it was introduced

The showEvent() lazy-load guard (m_rigsLoaded) was added to defer the expensive rig_load_all_backends() call until the HamLib tab is actually visited. This created the window where saveSettings() could be called before the combo was ever populated.

Fix

Guard the HamLibRigType write with m_rigsLoaded. If the combo was never populated this session, the existing config value is left untouched:

```cpp
if (m_rigsLoaded)
settings.setValue("HamLibRigType", ...);
```

Trigger conditions

• Most commonly: first run after a new version install, where checkIfNewVersion() forces the Settings dialog open and the user clicks OK after updating their callsign without visiting the HamLib tab.
• Also: any Settings open → OK without visiting the HamLib tab.

---

Bug 2: "Enable HamLib" checkbox shown unchecked/disabled

What happens

Opening the Settings → HamLib tab shows the "Enable HamLib" checkbox as unchecked and grayed out, even when HamLib was previously configured and enabled.

Root cause

Two issues working together:

a) setRigType() in loadSettings() calls setCurrentIndex() on the combo, which fires currentTextChanged → slotRadioComboBoxChanged() → setTestResult(false). setTestResult(false) unchecks and disables the activation checkbox — before loadSettings() has had a chance to restore it from config.

b) setDefaults() (called from the constructor) calls setTestResult(false), which disables the checkbox. loadSettings() calls setChecked() to restore the saved value, but never calls setEnabled(), so the checkbox remains disabled even when HamLibActive=true.

When it was introduced

The showEvent() lazy-load commit moved rig-list population out of createUI() and into showEvent(). Before that change, the combo was populated at construction time, and by the time loadSettings() was called the signal chain was less disruptive. The lazy-load commit exposed both issues simultaneously.

Fix

Two targeted changes to loadSettings():

```cpp
// Block signals so setRigType() cannot trigger setTestResult(false)
rigTypeComboBox->blockSignals(true);
setRigType(settings.value("HamLibRigType").toString());
rigTypeComboBox->blockSignals(false);

// Re-enable the checkbox if it was previously active
const bool wasActive = settings.value("HamLibActive", false).toBool();
activateHamlibCheckBox->setChecked(wasActive);
if (wasActive)
activateHamlibCheckBox->setEnabled(true);
```

---

Testing

• Confirmed with NET rigctl (model saved as non-zero ID).
• Open Settings, change something on any tab other than HamLib, click OK → rig type preserved.
• Open Settings, navigate to HamLib tab → "Enable HamLib" checkbox shown checked and enabled.
• Fresh install (no config) → checkbox correctly starts unchecked/disabled.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud