Allow building without wxMenuBar (but with wxMenu), as this class
doesn't exist and can't be reasonably implemented under iOS (but
wxMenu can and should be, as it's widely used in iOS 14 UI).
13068d3603 introduced code for stripping
CJK mnemonics (i.e. trailing " (&X)") from the menu items, but due to
the use of wxStripMenuCodes() in wxControl::GetLabelText(), it also
applied to the control labels, resulting in wrongly measuring their size
(because the text used for measurement didn't include the "(&X)" part)
and truncating them in display.
Fix this by adding an explicit wxStrip_CJKMnemonics and using it only in
the code dealing with the menu item labels. This requires more changes
than just modifying GetLabelText() to use some wxStrip_NoCJKMnemonics
flag, but is more compatible as it's not impossible that some existing
code using wxStripMenuCodes() could be broken by this change too, while
now the existing behaviour is preserved.
Also improve wxStrip_XXX documentation.
Closes https://github.com/wxWidgets/wxWidgets/pull/1439
See #16736.
Closes#18452.
No real changes, just clean up sources by removing trailing spaces from
all the non-generated files.
This should hopefully avoid future commits mixing significant changes
with insignificant whitespace ones.
This previously worked in wxGTK, but not in wxMSW and even under wxGTK
it could be surprising that the submenu got the event, but its parent
menu did not.
Make things consistent between the platforms and send the event to the
menu directly containing it first, but then also to its parent menu(s).
Document the new behaviour and verify that it works as intended with a
new unit test.
Closes#18202.
This is a micro-optimization, as pre-increment is at least as efficient
as post-increment and typically slightly more so because it doesn't need
to make a copy of the iterator, and better conforms to the prevailing
C++ style.
Closes https://github.com/wxWidgets/wxWidgets/pull/655
The argument to this method should basically just never be used, so while we
still keep it for compatibility (because it doesn't cost anything to do it),
make it clear that it should never be specified in the new code and, also,
that this function is actually only used inside wxWidgets and shouldn't be
normally called from outside of the library at all.
Send these events to the menu itself first, then to the menu bar containing
it or the window invoking it if it's a popup menu and, finally, to the top
level window in all of wxGTK, wxMSW and wxOSX.
In particular, this ensures that help strings are now shown in the parent MDI
frame status bar by default, even when the menus are attached to the client
MDI frame or shown as popup menus.
At the implementation level, this logic is now encapsulated in a new static
wxMenu::ProcessMenuEvent() method which can be easily modified and reused in
other ports.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78230 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This port is not used and is not being worked on, so remove it to reduce the
amount of the code which needs to be updated for every global change.
Also remove tests for VisualAge compiler which isn't used since ages.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76533 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
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
