Ported from reviewing rigexpert/AntScope2#29 for applicability here (review-only pass).
Upstream: rigexpert/AntScope2#29
The bug (upstream): on_selectDeviceDialog() runs a nested event loop via dlg.exec(), during which a pending QTimer::singleShot call to the same slot could in principle stack a second dialog on top of the first.
Status in AntScopeZ (checked 2026-09-08): already present, and more thoroughly documented. src/mainwindow_analyzer.cpp:251-280 (MainWindow::on_selectDeviceDialog()) already guards with an m_selectDeviceDialogOpen member flag, with an extensive comment explaining exactly this race (two independent triggers -- Settings' "Connect analyzer" button and the startup auto-reconnect fallback -- that could otherwise stack two instances), and why QApplication::activeModalWidget() alone isn't sufficient here. No action needed. Closing for the record.
Ported from reviewing rigexpert/AntScope2#29 for applicability here (review-only pass).
Upstream: rigexpert/AntScope2#29
The bug (upstream):
on_selectDeviceDialog()runs a nested event loop viadlg.exec(), during which a pendingQTimer::singleShotcall to the same slot could in principle stack a second dialog on top of the first.Status in AntScopeZ (checked 2026-09-08): already present, and more thoroughly documented.
src/mainwindow_analyzer.cpp:251-280(MainWindow::on_selectDeviceDialog()) already guards with anm_selectDeviceDialogOpenmember flag, with an extensive comment explaining exactly this race (two independent triggers -- Settings' "Connect analyzer" button and the startup auto-reconnect fallback -- that could otherwise stack two instances), and whyQApplication::activeModalWidget()alone isn't sufficient here. No action needed. Closing for the record.