wxMenu::Remove() was still broken in wxMSW after r75250, even with the fix in
r75290, as wxMSW code relied on the item still being present in
wxMenu::m_items.
Delay removing it from there until after DoRemove() call to fix this.
See #3424.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75297 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The menu items were not removed from the menu any longer when they were
deleted or destroyed after the changes in this revision.
Fix this by calling the public Remove(), which does the right thing, instead
of the private DoRemove(), which only does part of the job of removing the
item, in DoDelete() and DoDestroy().
See #3424.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75290 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The assert complained about a bug in wxMenu code itself, but actually could be
triggered by simply trying to remove a non-existent item from the menu.
Fix this by checking for the item existence, and also removing it from the
internal menu data structure, in wxMenuBase::Remove() and only dealing with
the item itself in DoRemove().
Closes#3424.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75250 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.
If nothing else, this will make an eventual transition to Git simpler.
Closes#14487.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Previously, wxGTK used the associated frame as wxMenuBar parent, while the
other ports did not. Do set the frame as menu bar parent in all ports now.
Of course, considering that wxMenuBar is not a window at all, this doesn't
necessarily make much sense, but at least it makes the behaviour consistent.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73923 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We handled the menu events in the menu itself and the associated window, but
not in the menu bar that the menu belonged to. This was unexpected, so allow
handling the events in the menu bar itself too.
Closes#15095.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73922 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Pass the menu event to the window associated with the menu first, before
falling back on wxApp.
This required adding yet another flag to keep state in wxEvent but it seems to
be unavoidable as wxMenuBase::SendEvent() calls ProcessEvent() twice and we
must have some way to distinguish the first call from the second one.
Added a test case verifying that the menu events are indeed processed in the
expected order.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73921 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use the same short names as are used by the event table macros for the event
type constants themselves. This makes them much more comfortable to use, e.g.
Bind(wxEVT_BUTTON) compared to Bind(wxEVT_COMMAND_BUTTON_CLICKED).
The old long names are still kept for backwards compatibility and shouldn't be
removed as it doesn't really cost anything to continue providing them, but all
new event types should only use the short versions.
Closes#10661.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73850 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is useless and can apparently result in some problems as of r25877 and
r25877 (from 8 years ago) added explicit checks preventing processing such
events in wxToolBar and wxMenu. Instead, simply don't generate these events in
the first place and also remove the now unnecessary checks for them.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70179 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use GetWindow() instead of GetInvokingWindow() to send the event to the
associated window for the menus that are part of the menu bar and not only the
popup ones. This was broken since r64127 because GetInvokingWindow() is now
only used for the popup menus.
Closes#13317.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68218 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
As wxAcceleratorEntry::Create() now expects the full menu item label, just
pass GetItemLabel() to it in wxMenuItemBase::GetAccel() instead of half-
parsing it ourselves there.
Closes#12794.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66430 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We don't need to call wxAcceleratorEntry::Create() in wxMenuItem::GetAccel()
if the menu item doesn't have any accelerator at all, i.e. if there is no TAB
in its label.
Calling wxAcceleratorEntry::Create() is useless and won't work correctly any
more when Create() is updated to allow passing it strings without TAB in them
in the next commit.
See #12745.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66307 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Add separators with correct kind, setting m_kind doesn't work any more because
it's overwritten below.
Also add a comment explaining why is overriding the user-specified kind the
right thing to do here.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64244 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We already check that positive (i.e. specified by user and not generated by
wx) window ids are in 0..SHRT_MAX range. Now do the same for the menu ids as
ids outside of this range suffer from the same problem under MSW: they get
wrapped and become negative when we receive events for them.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64226 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Only the top level menus have non-NULL wxMenuBar pointer too, so recurse
upwards the menu hierarchy in GetWindow() and not (just) GetInvokingWindow().
This fixes event processing for submenus broken by the recent changes.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64135 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Include wx/frame.h header instead of casting wxFrame to wxWindow using C style
cast. Although this does work now and probably will work later too it seems
better to not use the cast nevertheless.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64130 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This simplifies the code as we don't need to walk the menu hierarchy upwards
any more (GetInvokingWindow() does it now) and also makes it work for all
menus, not just the popup ones.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64126 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
GetInvokingWindow() can only be used for the popup menus which have the
invoking window, so add a new function which can be used to get the window
associated with any kind of menu in all ports -- it already existed in wxMSW
but is needed elsewhere too.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64123 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
SetInvokingWindow() is only called for the top menu being popped up itself but
the invoking window should also be associated with its submenus.
Modify GetInvokingWindow() to return the parents invoking window for submenus.
This fixes a crash due to returning NULL from wxMenu::GetWindow() in wxMSW
owner-drawn code.
And it also makes redundant some code in wxUniversal wxMenu implementation
which can now simply use GetInvokingWindow() in all cases.
Closes#11957.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64104 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
It doesn't make sense to add a menu with empty title to the menu bar so assert
that the title is not empty and fail to add the menu if it is.
See r64033 in wxQT branch.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64058 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
