Opened 15 months ago

Closed 13 months ago

Last modified 13 months ago

#15479 closed defect (wontfix)

wxMenu sends events in inappropriate order

Reported by: orson Owned by:
Priority: normal Milestone:
Component: GUI-all Version: 2.9.5
Keywords: wxMenu event close selected Cc:
Blocked By: Blocking:
Patch: no

Description

When closing a wxMenu by selecting an item, it sends first wxEVT_MENU_CLOSE event and then wxEVT_COMMAND_MENU_SELECTED. It makes harder to decide if user has closed the menu by choosing anything or simply dismissed it.
In the attachment there is code to test the case.
wxWidgets built from Arch AUR (https://aur.archlinux.org/packages/wx/wxwidgets/PKGBUILD)

Attachments (1)

wxhello.cpp download (2.2 KB) - added by orson 15 months ago.
Test program that recreates the bug.

Download all attachments as: .zip

Change History (4)

Changed 15 months ago by orson

Test program that recreates the bug.

comment:1 Changed 15 months ago by pcor

  • Component changed from wxGTK to GUI-all

wxMSW behaves the same way.

comment:2 Changed 13 months ago by vadz

  • Resolution set to wontfix
  • Status changed from new to closed

If the behaviour is consistent between the two ports, we are not going to change this, so I'm closing it, especially because in my opinion it's not a good idea at all to rely on detecting whether the user selected anything from the menu, this is clearly just too fragile (just think about some ports such as wxWinCE which might not be using menus at all).

If you absolutely want something like this you probably still can detect it using CallAfter(), but I strongly recommend not trying to do it.

comment:3 Changed 13 months ago by VZ

(In [75007]) Document that wxEVT_MENU_CLOSE can come before wxEVT_MENU.

This is somewhat unexpected but is how both wxMSW and wxGTK work currently, so
just document the current behaviour.

See #15479.

Note: See TracTickets for help on using tickets.