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
When wxMenu contains radio groups and a new item (radio and non-radio) is
being added to the menu, data describing exisiting groups have to
be updated accordingly. Because adding radio and non-radio items has
a different impact on the groups, adding non-radio items has to be handled
separately. (The main difference between adding radio and non-radio item is
that when a radio item is inserted inside the group this group is extended,
but for non-radio item the group is split into two subgroups.)
wxMSW propagates accelerators to the top menu in wxMenu::UpdateAccel(),
but the reverse operation in wxMenu::DoRemove() didn't do it, resulting
in leaked leftover accelerator entries that could prevent the same
accelerator from working if an item using it was later added. Fix by
adding RemoveAccel() helper method that behaves analogously to
UpdateAccel().
When menu item is inserted to the menu using wxMenu::DoInsert(), it is first
added to the list of all menu items in wxMenuBase::DoAppend() and then it is
added to the physical menu in wxMenu::DoInsertOrAppend(). Prior to adding the
menu item to the menu all already existing menu items are set as owner drawn,
so the list of items is iterated and SetOwnerDrawnMenuItem() is called for
each item. Because the new item is on the list but doesn't yet physically
exist, it has to be skipped in the iterations to avoid assigning wrong data
(like address of handler) to the wrong item.
Closes#17350.
A variable was unused in wxDEBUG_LEVEL==0 build and assigning to it resulted
in a warning. Fix this by not defining this variable at all, which also makes
the check more clear.
Windows CE doesn't seem to be supported by Microsoft any longer. Last CE
release was in early 2013 and the PocketPC and Smartphone targets supported by
wxWidgets are long gone.
The build files where already removed in an earlier cleanup this commit
removes all files, every #ifdef and all documentation regarding the Windows CE
support.
Closes https://github.com/wxWidgets/wxWidgets/pull/81
Selecting an already selected radio menu item didn't generate any events in
wxGTK nor in wxMSW with the top level (i.e. attached to a menu bar) menus but
did send them for popup menus under MSW.
Make the last case consistent with the rest of them and don't send any events
in this case neither.
Closes#16891.
This doesn't make any sense, this function is not related to the owner drawing
code at all and should always be available.
This corrects the changes of r70316, see #13851.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78232 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This assert was triggered after the changes of the previous commit as we can
get WM_MENUSELECT with menu bar handle as parameter from Windows and still
search for the menu with this handle -- and there is nothing wrong with this,
so just return NULL but without asserting in this case.
This corrects the changes of r67355, see #13080.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78231 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Add argument to a call to GetHBitmapForMenu, which doesn't have a default
parameter any more. Fixes (this part of) WinCE compilation. Broken since
r76760.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76780 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Merge wxMenuItem::GetHBitmapForMenuCheckable and ::DoGetHBitmapForMenu
into wxMenuItem::GetHBitmapForMenu. Change its boolean parameter to an
enum specifying the kind of bitmap that is wanted (normal, checked, or
unchecked).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76760 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Since r76202 InsertMenuItem is used when adding checkable menu items even
without a bitmap. The call fails because hbmpChecked and hbmpUnchecked are
set to HBMMENU_CALLBACK on pre-Vista, making the menu owner drawn
unnecessarily.
Fix by adding GetHBitmapForMenuCheckable which is used when assigning
values to hbmpChecked and hbmpUnchecked. GetHBitmapForMenu remains
unchanged (for possible porting reasons) and is used for hBmpItem only.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76757 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The user-visible effect of this change is that removing the item from the menu
and adding it back doesn't lose its icon any more.
At the code level, wxMenuItem::SetBitmaps() and related methods are
implemented outside of "#if wxUSE_OWNER_DRAWN" which allows to use them even
in minimalistic library builds. And IsOwnerDrawn() is not used any more to
determine whether the item has bitmaps, just only if it's really owner drawn,
making the code more clear and fixing at least the bug above and possible more.
Closes#13878.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76202 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
No real changes, just make it clear that this method is MSW-specific and is
about using owner drawn items at MSW level and not wx one.
See #13878.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76201 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The changes of r75448 were wrong, we can't ask Windows for the item state
before attaching it to the menu, so just check the internal flag here.
See ##15748.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75570 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Typical wxScopedArray initialization uses "new T[n]" expression, allow to omit
most of it and specify just n, the number of elements to allocate.
Use the new shorter form in the places where wxScopedArray(new ...) was used
(which is in almost all of them)
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75504 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Calling wxMenuItem::Check() before appending the item to a menu didn't have
any effect, fix this by checking the item state when actually attaching it.
Closes#15748.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75448 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
Account for the "Window" menu (and any other foreign windows lurking in our
menu bar) correctly in wxMenuBar::Insert() instead of the old code which
apparently tried to do something similar but didn't make much sense and didn't
work when trying to insert the menu at the position actually occupied by the
"Window" menu in the menu bar.
Closes#15662, #1732.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75241 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The check for menu bitmaps size added in r58557 was apparently only needed for
XP and earlier versions and doesn't seem to be necessary under Win7, so don't
use it there, if only because it allows to retrieve the menu item text which
is useful for automation/screen reader tools.
Closes#13544.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75001 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The item being inserted is not inserted yet when we call
SetOwnerDrawnMenuItem() so we must call it separately for it after inserting
it.
Closes#15437.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74717 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
We didn't update the accelerator table if no more accelerators were left in it
but we still need to do it to stop handling the previously active accelerators.
Closes#15078.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73594 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use t_str() instead of wx_str() to make the code work correctly in UTF-8 build
in which wx_str() returns a pointer to UTF-8 buffer while we need a wchar_t
pointer for Windows.
Closes#14371.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@71640 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use WinStruct instead of the usual ZeroMemory() + cbSize setting fragment to
initialize Win32 structs that need to be initialized in this way.
No real changes.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70383 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
Fix the checks added in r70316, wxUSE_OWNER_DRAWN should have been used
instead of inexistent and undefined wxUSE_OWNER_DRAW.
See #13851.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70343 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Allow compiling with wxUSE_OWNER_DRAW==0. This fixes another problem in
Windows CE build where owner drawn menus are not supported.
Closes#13851.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70316 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Set the int field of wxCommandEvent generated by clicking on the menu items
correctly for not checkable items: it is supposed to be -1 and not 0 (which is
the value for checkable but currently unchecked items). This was already the
case for wxGTK and wxOSX and implied by the comments in the code.
Make wxMSW behave like this too and clearly document this behaviour.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@69101 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
