Request preparation
What would you like?
What happened?
The fix applied in v0.7.18.6 to address issue #618 (prevent accidental value changes from mouse wheel hover on unfocused combo boxes) has the behavior exactly inverted from what was intended:
When the combo box is closed and has NOT been clicked/focused, scrolling the mouse wheel over it still changes the selected value — the original unwanted behavior that #618 was filed to fix.
After the combo box is clicked and the drop-down list is open, scrolling the mouse wheel does nothing — the one situation where wheel input is actually desired and expected.
The net result is that the fix both fails to prevent accidental changes and breaks intentional interaction.
What did you expect?
Mouse wheel input on a QComboBox should be gated on whether the drop-down popup is currently visible:
Popup closed (regardless of focus state): wheel events should be ignored, preventing accidental value changes when the user is scrolling the wider UI and the cursor happens to pass over a combo box.
Popup open (user has clicked the control and the list is displayed): wheel events should scroll through the list values as normal, allowing deliberate selection.
This is the standard behavior users expect from combo boxes in professional desktop applications, and what was described as the intended fix in issue #618.
Steps to reproduce
Launch AetherSDR 0.7.18.6 on Windows and connect to a FLEX-6600.
Locate any QComboBox control in the UI (e.g. the antenna selector, AGC mode, TX profile dropdown, mic profile dropdown, or DAX rate in PanadapterApplet).
Without clicking the combo box, hover the mouse cursor over it and scroll the mouse wheel.
Observe: The combo box value changes — this is the regression (the original bug #618 is still present).
Now click the combo box to open the drop-down list.
With the drop-down list visible, scroll the mouse wheel.
Observe: The wheel input has no effect and does not scroll through the list values — the desired interaction is broken.
Radio model & firmware
Radio: FLEX-6600
Firmware: 4.1.5.39794
OS & version
OS: Windows
AetherSDR version: 0.7.18.6
Qt version: 6.7.3
Developer Notes
Root cause analysis:
The fix in #618 almost certainly installed a wheelEvent override or an eventFilter on QComboBox that checks focus state rather than popup visibility. The two states are not equivalent: a QComboBox can receive focus (e.g. via tab key) without its popup being open, and conversely the popup can be open while the combo technically reports focus to its parent widget differently depending on platform. On Windows in particular, Qt's focus model for QComboBox popups differs from Linux.
The condition that should gate wheel input is QComboBox::view()->isVisible() (or equivalently checking the internal popup's visibility), not hasFocus() or underMouse().
Most likely involved source files:
src/gui/ComboStyle.h — described in the architecture as the "shared dark combo box styling helper." If the wheel event fix was applied here as a shared subclass or an installed event filter, this is the primary location to audit. Look for a wheelEvent() override or an eventFilter() checking QEvent::Wheel.
src/gui/RxApplet.cpp — contains antenna, AGC mode, and step-size combo boxes; likely applies ComboStyle or installs its own wheel guard.
src/gui/TxApplet.cpp — TX profile dropdown.
src/gui/PhoneCwApplet.cpp and src/gui/PhoneApplet.cpp — mic profile and mic source combo boxes.
src/gui/PanadapterApplet.cpp — DAX rate and FPS combo boxes.
The fix:
The wheel event guard condition should be changed from whatever focus-based check is currently used to a popup-visibility check. A correct implementation:
cpp// In a QComboBox subclass or event filter:
void MyComboBox::wheelEvent(QWheelEvent e)
{
// Only allow wheel input when the drop-down popup is open
if (view() && view()->isVisible())
QComboBox::wheelEvent(e);
else
e->ignore();
}
If the fix is implemented as an event filter (installed on all combo boxes via ComboStyle), the same logic applies — check qobject_cast<QComboBox>(watched)->view()->isVisible() rather than any focus predicate.
Why this is inverted on Windows specifically: Qt's QComboBox on Windows uses a native popup widget. When the popup opens, the combo box itself may lose Qt-level focus to the popup's internal QAbstractItemView. A hasFocus() check on the combo box will therefore return false precisely when the popup is open — exactly backwards from the intent. The view()->isVisible() check is platform-agnostic and correctly reflects popup state on all platforms.
Logging / diagnostics: No special logging categories are needed to reproduce this — it is directly observable. A developer can confirm the inverted guard by adding a qDebug() trace to the wheel event handler and logging hasFocus(), view()->isVisible(), and whether the event is accepted or ignored at each scroll event.
A search should be conducted to identify all instances of this particular QCombobox.
Request preparation
What would you like?
What happened?
The fix applied in v0.7.18.6 to address issue #618 (prevent accidental value changes from mouse wheel hover on unfocused combo boxes) has the behavior exactly inverted from what was intended:
When the combo box is closed and has NOT been clicked/focused, scrolling the mouse wheel over it still changes the selected value — the original unwanted behavior that #618 was filed to fix.
After the combo box is clicked and the drop-down list is open, scrolling the mouse wheel does nothing — the one situation where wheel input is actually desired and expected.
The net result is that the fix both fails to prevent accidental changes and breaks intentional interaction.
What did you expect?
Mouse wheel input on a QComboBox should be gated on whether the drop-down popup is currently visible:
Popup closed (regardless of focus state): wheel events should be ignored, preventing accidental value changes when the user is scrolling the wider UI and the cursor happens to pass over a combo box.
Popup open (user has clicked the control and the list is displayed): wheel events should scroll through the list values as normal, allowing deliberate selection.
This is the standard behavior users expect from combo boxes in professional desktop applications, and what was described as the intended fix in issue #618.
Steps to reproduce
Launch AetherSDR 0.7.18.6 on Windows and connect to a FLEX-6600.
Locate any QComboBox control in the UI (e.g. the antenna selector, AGC mode, TX profile dropdown, mic profile dropdown, or DAX rate in PanadapterApplet).
Without clicking the combo box, hover the mouse cursor over it and scroll the mouse wheel.
Observe: The combo box value changes — this is the regression (the original bug #618 is still present).
Now click the combo box to open the drop-down list.
With the drop-down list visible, scroll the mouse wheel.
Observe: The wheel input has no effect and does not scroll through the list values — the desired interaction is broken.
Radio model & firmware
Radio: FLEX-6600
Firmware: 4.1.5.39794
OS & version
OS: Windows
AetherSDR version: 0.7.18.6
Qt version: 6.7.3
Developer Notes
Root cause analysis:
The fix in #618 almost certainly installed a wheelEvent override or an eventFilter on QComboBox that checks focus state rather than popup visibility. The two states are not equivalent: a QComboBox can receive focus (e.g. via tab key) without its popup being open, and conversely the popup can be open while the combo technically reports focus to its parent widget differently depending on platform. On Windows in particular, Qt's focus model for QComboBox popups differs from Linux.
The condition that should gate wheel input is QComboBox::view()->isVisible() (or equivalently checking the internal popup's visibility), not hasFocus() or underMouse().
Most likely involved source files:
src/gui/ComboStyle.h — described in the architecture as the "shared dark combo box styling helper." If the wheel event fix was applied here as a shared subclass or an installed event filter, this is the primary location to audit. Look for a wheelEvent() override or an eventFilter() checking QEvent::Wheel.
src/gui/RxApplet.cpp — contains antenna, AGC mode, and step-size combo boxes; likely applies ComboStyle or installs its own wheel guard.
src/gui/TxApplet.cpp — TX profile dropdown.
src/gui/PhoneCwApplet.cpp and src/gui/PhoneApplet.cpp — mic profile and mic source combo boxes.
src/gui/PanadapterApplet.cpp — DAX rate and FPS combo boxes.
The fix:
The wheel event guard condition should be changed from whatever focus-based check is currently used to a popup-visibility check. A correct implementation:
cpp// In a QComboBox subclass or event filter:
void MyComboBox::wheelEvent(QWheelEvent e)
{
// Only allow wheel input when the drop-down popup is open
if (view() && view()->isVisible())
QComboBox::wheelEvent(e);
else
e->ignore();
}
If the fix is implemented as an event filter (installed on all combo boxes via ComboStyle), the same logic applies — check qobject_cast<QComboBox>(watched)->view()->isVisible() rather than any focus predicate.
Why this is inverted on Windows specifically: Qt's QComboBox on Windows uses a native popup widget. When the popup opens, the combo box itself may lose Qt-level focus to the popup's internal QAbstractItemView. A hasFocus() check on the combo box will therefore return false precisely when the popup is open — exactly backwards from the intent. The view()->isVisible() check is platform-agnostic and correctly reflects popup state on all platforms.
Logging / diagnostics: No special logging categories are needed to reproduce this — it is directly observable. A developer can confirm the inverted guard by adding a qDebug() trace to the wheel event handler and logging hasFocus(), view()->isVisible(), and whether the event is accepted or ignored at each scroll event.
A search should be conducted to identify all instances of this particular QCombobox.