Skip to content

Bug / Feature Request: Combo Box Drop-Down Lists Should Not Respond to Scroll Wheel #618

Description

@rnash2

Request preparation

  • I used an AI assistant to help structure this request
  • I checked for existing issues covering the same feature

What would you like?

Bug / Feature Request: Combo Box Drop-Down Lists Should Not Respond to Scroll Wheel

Area: UI / Display — all QComboBox widgets across all applets and dialogs


Summary

All drop-down list controls (QComboBox) in AetherSDR currently change their selected value when the user scrolls the mouse wheel over them, even without clicking the control first. This causes unintentional changes to radio settings during normal operation and is inconsistent with the behavior of FlexRadio SmartSDR, where scroll wheel input on drop-down lists is ignored.


Problem / Use Case

Operators using a free-spinning or high-inertia scroll wheel mouse (commonly used to replicate the feel of a physical VFO knob) are particularly affected. The scroll wheel may continue spinning after a VFO tuning action, and if the cursor happens to be near any combo box — mode selector, antenna selector, AGC mode, mic profile, TX profile, filter preset, DAX channel, etc. — the control will silently cycle through its values. The operator may not notice the change until a setting causes an unexpected result on-air.

This behavior affects every QComboBox in the application, including but not limited to:

  • Mode selector
  • Antenna selector (RX applet)
  • AGC mode (RX applet)
  • Mic profile / mic source (P/CW applet)
  • TX profile (TX applet)
  • DAX channel selectors (CAT applet)
  • Filter presets
  • Any combo boxes in the Radio Setup dialog tabs

SmartSDR does not change combo box values on scroll wheel input — only an explicit click-and-select interaction changes the value. AetherSDR should match this behavior.


Root Cause

This is a known default Qt behavior. QComboBox widgets capture and act on QWheelEvent by default, regardless of whether the widget has keyboard focus. The fix is to subclass QComboBox (or install an event filter) to suppress QWheelEvent unless the drop-down list is currently open.


Proposed Fix

Create a single shared NoScrollComboBox subclass (or equivalent event filter utility) and use it everywhere in AetherSDR in place of bare QComboBox:

// src/gui/NoScrollComboBox.h
class NoScrollComboBox : public QComboBox {
    Q_OBJECT
public:
    explicit NoScrollComboBox(QWidget* parent = nullptr) : QComboBox(parent) {
        // Prevent scroll wheel from stealing focus and changing value
        setFocusPolicy(Qt::StrongFocus);
    }
protected:
    void wheelEvent(QWheelEvent* e) override {
        // Only allow scroll wheel interaction when the drop-down is open
        if (view()->isVisible())
            QComboBox::wheelEvent(e);
        // Otherwise silently ignore
    }
};

Setting Qt::StrongFocus means the widget only accepts focus (and therefore scroll wheel events) when the user explicitly clicks or tabs into it — matching SSDR behavior.

All existing QComboBox instantiations across the codebase should be replaced with NoScrollComboBox. AetherSDR already has a pattern for shared GUI helpers (see ComboStyle.h, HGauge.h) so a header-only implementation fits naturally alongside those.


Affected Files (likely incomplete — a codebase search for QComboBox will give the full list)

  • RxApplet — antenna, AGC mode
  • TxApplet — TX profile
  • PhoneCwApplet — mic profile, mic source
  • PhoneApplet — (any combos)
  • CatApplet — DAX channel selectors
  • PanadapterApplet — DAX rate
  • RadioSetupDialog — multiple tabs
  • ProfileManagerDialog
  • VfoWidget — mode selector
  • Any other widget containing a QComboBox

Implementation Notes (for contributors)

  • A codebase-wide search for QComboBox (and new QComboBox, QComboBox*) will identify every instantiation that needs replacing.
  • If any combo boxes are created via Qt Designer .ui files, the subclass can be promoted in Designer, or the .ui XML can be edited to use NoScrollComboBox as a custom widget.
  • The view()->isVisible() check ensures scroll wheel still works as expected when the user has deliberately opened the drop-down list — only unsolicited scroll events are suppressed.
  • This change has no effect on the radio protocol layer — it is entirely client-side UI.
  • Consistent with ComboStyle.h existing as a shared helper, NoScrollComboBox.h should live in src/gui/ as a header-only class.

Acceptance Criteria

  • Scrolling the mouse wheel over any closed combo box does not change its value
  • Clicking a combo box to open the drop-down, then scrolling, still navigates the list as expected
  • All combo boxes across all applets, dialogs, and widgets are covered — no QComboBox instances remain that respond to unsolicited scroll input
  • Behavior matches SmartSDR: only explicit click-and-select changes a combo box value
  • No regression in combo box styling (dark theme via ComboStyle.h unchanged)

Labels: bug, UI
Note: This is a particularly high-impact fix for operators using free-spinning or high-inertia scroll wheel mice for VFO tuning.

Metadata

Metadata

Assignees

No one assigned

    Labels

    GUIUser interfacebugSomething isn't working

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions