#14961 closed defect (fixed)

wxGTK modal wxDialog contextmenus no longer work properly since r73007

Reported by: dghart Owned by: vadz
Priority: normal Milestone: 2.9.5
Component: wxGTK Version: stable-latest
Keywords: contextmenu modal dialog regression Cc:
Blocked By: Blocking:
Patch: yes

Description

r73007 fixed the unity bug #14823 by disabling menu events in a modal wxDialog. However this also prevents the dialog's contextmenu from achieving anything: the menu still appears and an item can be selected, but the handler never gets called. This can be seen in the attached 'minimal' sample diff.

Is it possible somehow to identify contextmenu events and allow them to be processed?

Attachments (3)

minimal.diff download (2.4 KB) - added by dghart 21 months ago.
menu.diff download (1.4 KB) - added by dghart 21 months ago.
menu1.diff download (391 bytes) - added by dghart 20 months ago.

Download all attachments as: .zip

Change History (12)

Changed 21 months ago by dghart

comment:1 follow-up: Changed 21 months ago by vadz

  • Keywords regression added
  • Status changed from new to confirmed

We need to check if wxMenu::GetInvokingWindow() returns a (child of a) modal dialog.

Changed 21 months ago by dghart

comment:2 in reply to: ↑ 1 Changed 21 months ago by dghart

Replying to vadz:

We need to check if wxMenu::GetInvokingWindow() returns a (child of a) modal dialog.

Yes, that works. Thank you.

The patch works for both the test and for my real-world dialog. I checked on unity, and it doesn't interfere with the #14823 fix.

comment:3 Changed 20 months ago by neis

  • Patch set

comment:4 follow-up: Changed 20 months ago by vadz

  • Owner set to vadz
  • Status changed from confirmed to accepted

It looks like we should be able to use GetWindow() in both cases, allowing us to avoid code duplication, or is there any problem with doing this? Please let me know if you find any problems with my version (which I'm about to commit).

And thanks for finding and fixing this!

comment:5 Changed 20 months ago by VZ

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [73365]) Relax Unity menu interdiction hack to allow popup menus in modal dialogs.

The changes of r73007 fixed the problem with menus remaining active while a
modal dialog was shown (see #14823) but also disabled processing of the events
from any popup menus shown by the dialog itself. Reallow the latter while
still forbidding the former now by checking whether the window associated with
the menu is the dialog itself.

Closes #14961.

comment:6 Changed 20 months ago by VZ

(In [73367]) Fix compilation without PCH after r73365.

Need to explicitly include wx/dialog.h to use wxDynamicCast to wxDialog.

See #14961.

comment:7 in reply to: ↑ 4 Changed 20 months ago by dghart

  • Resolution fixed deleted
  • Status changed from closed to reopened

Replying to vadz:

It looks like we should be able to use GetWindow() in both cases, allowing us to avoid code duplication, or is there any problem with doing this? Please let me know if you find any problems with my version (which I'm about to commit).

r73367 should return false inside the 'if'; fixed in menu1.diff. Otherwise I confirm that your method works, both in unity and in sane DEs.

Changed 20 months ago by dghart

comment:8 Changed 20 months ago by vadz

Oops. Thanks for retesting and sorry for the stupid bug.

comment:9 Changed 20 months ago by VZ

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [73368]) Fix wrong return value in the changes of r73365.

Really fix menus under Unity.

Closes #14961.

Note: See TracTickets for help on using tickets.