Re: wx.ProgressDialog shows the "close" button even without PD_CAN_ABORT (#13413)

[Richard Thomson]

LegalizeAdulthood left a comment (wxWidgets/wxWidgets#13413)

I checked this against the current tree on Windows using the rt-default build.

Verification:

• Built the dialogs sample target successfully.
• Ran dialogs.exe --progress 0, which creates a startup wxProgressDialog without wxPD_CAN_ABORT.
• While the progress dialog titled Progress in progress was active, inspected the native window state:
  • the system menu SC_CLOSE item was disabled/grayed (GetMenuState() returned 0x20000001),
  • the visible task-dialog button text was Close,
  • that Close button was disabled.

The current source matches this behaviour too: the generic path disables the title-bar close button when wxPD_CAN_ABORT is absent, and the native MSW TaskDialog path disables both the task-dialog close/cancel button and the title-bar close button until completion.

This appears to be already addressed in the current tree.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you authored the thread.Message ID: <wxWidgets/wxWidgets/issues/13413/4941213468@github.com>

[Bryan Petty]

Closed #13413 as completed.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you authored the thread.Message ID: <wxWidgets/wxWidgets/issue/13413/issue_event/27933859075@github.com>

[paulcor]

paulcor left a comment (wxWidgets/wxWidgets#13413)

Although this was reported against wxMSW, it looks like wxGTK (and probably all the other ports using generic wxProgressDialog) also has this issue, so I'm not sure it should be closed.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you authored the thread.Message ID: <wxWidgets/wxWidgets/issues/13413/4964741360@github.com>

[Richard Thomson]

LegalizeAdulthood left a comment (wxWidgets/wxWidgets#13413)

I checked this in the current tree at abed9fc, and the generic-port problem still seems real.

include/wx/progdlg.h only selects the native wxProgressDialog for non-Universal wxMSW; otherwise wxProgressDialog is just the generic wxGenericProgressDialog wrapper.

The generic dialog uses wxDEFAULT_DIALOG_STYLE, which includes wxCLOSE_BOX, so non-MSW generic dialogs get a title-bar close button by default.

src/generic/progdlgg.cpp disables that title-bar close button only inside #if defined(__WXMSW__) && !defined(__WXUNIVERSAL__).

When wxPD_CAN_ABORT is not set, generic sets m_state to Uncancelable, and OnClose() vetoes the close event, so the close affordance remains visible but inert.

So this still affects ports using generic wxProgressDialog, including wxGTK, wxOSX, wxQt, wxUniversal, and any other generic user. wxGTK and wxOSX even have EnableCloseButton(false) implementations, but the current generic code excludes them from the call.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you authored the thread.Message ID: <wxWidgets/wxWidgets/issues/13413/4964950951@github.com>