Ensure that an idle event is generated after a menu event even when the latter
comes, via DBUS, from the out of process app menu and not from a real GTK menu.
Closes#15122.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73737 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
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.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73365 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
because gtk_menu_item_set_submenu() with NULL menu argument does not work
before GTK 2.12 and there is no need to avoid calling it on later GTK2 versions
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73296 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Normally menus are disabled in this case but not when running under Ubuntu
Unity, so add an explicit test for this to avoid breaking the program expected
flow of control by allowing the user to show the same modal dialog twice, for
example.
This is not ideal, it would be better to visually disable the menu while the
modal dialogs are shown but is better than nothing.
Closes#14823.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73007 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This results in the destruction of the widgets of all of its menu and when
wxMenu objects are themselves destroyed in the base class dtor, we try to
destroy their already destroyed widgets, resulting in critical GTK warnings.
Simply don't do anything in wxMenuBar dtor itself if the menu bar is not
attached to a frame as the workaround was only needed in case of destroying
attached menu bars.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@72560 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Reset m_focusWidget to NULL when destroying m_widget in wxMenuBar dtor,
otherwise we try to use this already destroyed (because it's the same as
m_widget) widget in wxWindow dtor later resulting in critical GTK warnings.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@72559 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Ignore "hide" signals for the menus without associated shown window. Ubuntu
Unity sends them and we crashed because of a recursive assert in the
corresponding signal handler before.
Now the code doesn't crash any more but the menus still don't behave correctly
when the last MDI child is destroyed.
Closes#13593.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@72379 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
"LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that doesn't believe we're it's parent."
Avoid calling gtk_widget_destroy() on a wxMenuBar attached to a frame
Fixes#14292
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@71648 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This method was only available in wxUniv before and just always returned true
in the other ports. Implement it for wxMSW and wxGTK too now and document it.
Also add a unit test.
Closes#795.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70350 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
In GTK+ 2.10 and earlier gtk_menu_item_remove_submenu() had to be used to
remove the items submenu as gtk_menu_item_set_submenu() gave errors when
passed NULL submenu, so call the old function when using old GTK+ version.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@69947 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
After fixing the insertion of radio menu items in wxMSW, also do it for wxGTK
to make the newly added unit test pass there as well.
Remove the unneeded wxMenu::m_prevRadio which doesn't make any sense neither
(just as the "current radio group" pointer removed from wxMSW code before) and
simply use the radio group of the existing item this radio item is being
inserted before or after instead.
See #13200.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67721 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxMenu::GetTitle() returned a string in GTK+ format (i.e. using underscores
instead of ampersands) instead of the expected wx one.
This is, of course, the right thing to do and it also fixes
wxMenuBar::FindMenuItem() as a side effect.
Closes#12672.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66175 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The "hide" signal handler was triggered when destroying a sub-menu (even if it
was not shown at this time). Disconnect it to avoid asserts due to attempts to
generate an event for an already detached menu and to avoid the (bogus)
wxEVT_MENU_CLOSE event as well.
Closes#12668.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66082 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxGTK wxMenuBar used its own SetInvokingWindow/UnsetInvokingWindow() and
related functions instead of reusing the base class Attach/Detach() which
exist for exactly the same purpose. This resulted in unnecessary code
duplication and confusion and, since the changes of r64104, resulted in
asserts due to use of SetInvokingWindow() for non-popup menus.
Fix this by removing the wxGTK-specific functions and doing the work they used
to do in (now overridden) Attach() and Detach(). Also call Attach/Detach()
instead of these functions from wxGTK wxFrame and wxMDIParentFrame code.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64127 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Reuse the existing DoCommonMenuCallbackCode() function instead of duplicating
its code in menuitem_select() and menuitem_deselect() GTK callbacks.
No changes in behaviour.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64125 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
