This is similar to f74379c751 but specific to
wxMSW MDI code: also call wxMenu::UpdateUI() without any parameters from it
instead of overriding its logic for determining where to send the events.
Add code to the mdi sample demonstrating that the event handlers in the window
itself and its MDI frame parent get the events they're supposed to get.
See #17352.
Ask the user when closing the window with several MDI frames opened, if only
to demonstrate how to do it, but not if there is only one window as this is
just too annoying when using the sample for testing.
Make wxGenericListCtrl used under wxGTK and wxOSX behave the same as the
native wxMSW wxListCtrl and wxTreeCtrl under all platforms and only generate
ITEM_RIGHT_CLICK events when an item was actually clicked, i.e. don't generate
them for the clicks completely outside of the client area.
Closes#4711.
Don't build if configure failed and don't build tests if building the library
failed and so on: contrary to the expectations, Travis continues to execute
the rest of the commands even if a previous one had failed, so chain them all
explicitly together using "&&" to make sure we fail as soon as possible.
See https://github.com/travis-ci/travis-ci/issues/1066
This is more correct than IsTopLevel() as accelerators shouldn't traverse the
"navigation domain" boundaries, by definition, and, even more importantly in
practice, some TLWs shouldn't stop the accelerators propagation, see the next
commit.
See #16870.
Ignore the unrelated mouse events during the item dragging.
This avoids a crash due to m_actionItem being NULL when right clicking an item
while the left mouse button is kept pressed.
Closes#16327.
(this is a forward port of 648d9ce1fbd6d4f2241eda764f2a9679aed6b2c4 from 3.0)
Don't call wxMenu::UpdateUI() explicitly in wxMSW, wxGTK and wxOSX code before
showing the popup menu as it is also called when any menu is opened from
port-independent wxFrameBase wxEVT_MENU_OPEN handler, resulting in two events
being generated.
But also don't send the events from wxFrameBase handler only to the frame
itself, by explicitly passing "source" argument to wxMenu::UpdateUI(), as this
prevented the event from being sent to the window popping up the menu. By just
omitting this parameter we ensure that this event is sent to the right window.
Closes#17352 (but notice that there are still duplicate events under OS X,
see #17354).
This reverts commit 62763ad541 which seems to
have been completely unnecessary as the fields had been already initialized
and this commit actually broke initialization of the propagation level of the
copied wxCommandEvent objects.
Add a unit test proving that things do work.
Closes#16739.
Don't call GetSize() method as gcc can't handle aggregates returned by value
from D2D libraries currently and the code just crashes if this method is
called.
See #17171.
This reverts 54753c3d75 and (partially)
dbd5b2ce42 (leaving the unit test added by it)
and implements yet another fix for the original problem of duplicate
wxContextMenuEvents generated in wxMSW which doesn't break the generation of
wxContextMenuEvents entirely in wxTreeCtrl.
wxTreeCtrl is special as its DefWindowProc() sends WM_CONTEXTMENU directly to
its parent, and not to the control itself, when handling WM_RBUTTONUP, so the
code checking that WM_CONTEXTMENU was not coming from one of the window own
children added in dbd5b2 filtered out all messages from it completely. As it's
probably not the only control behaving in this way, abandon the idea of the
message origin check and instead set things up so that we still pass the
message to DefWindowProc() (because not doing it breaks built-in context menus
in wxTextCtrl, for example), but don't do anything when the message is
propagated upwards from it.
This should ensure that we only process the message once in MSWHandleMessage()
of the first window which gets it, whether it's the original window or its
parent, which ensures the event propagation on wxWidgets side of things, but
prevents it being done by Windows itself.
See #13683.
Since the changes to use IRichEditOleCallback in wxMSW wxTextCtrl (i.e.
bd650ec3d9 in master), wxEVT_CONTEXT_MENU was
not sent for it any more as the control consumed it after using the callback.
Send the event manually before the default handling takes place to fix this.
It is not really clear if it can happen, but avoid integer underflow in case
it somehow does and just discard the single byte which can't represent a valid
UTF-16 character anyhow.
See #16719.
Instead of asserting, report a user-visible error when trying to use a wrong
key, this should give more information to the developers and users if (when)
things go wrong.
See #16719.
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.
At least when using standard fonts under MSW, the underlines under the
consecutive words didn't overlap, resulting in ugly gaps between them when
using more than one word as the link text, for example.
Work around this by drawing an extra, slightly offset, underlined space when
the previous cell was drawn underlined.
We need these options in both CXXFLAGS and OBJCXXFLAGS, otherwise
Objective-C++ code would fail to compile when including C++11 headers such as
<type_traits>.
Tools containing controls should be enabled/disabled in a different way from
the button tools in wxToolBar::DoEnableTool(). The control and its label (if
any) need to be explicitly enabled/disabled for wxToolBarBase::EnableTool() to
work properly.
Closes#17346.
When computing the best control width from height, or vice versa, don't
account for the border size twice, once inside ListView_ApproximateViewRect()
and another time in our own code in the base class.
As we can't change the former, just compensate what the latter does by
returning the best width or height of the client part of the control, as
indicated by the DoGetBestClient{Height,Width}() methods names.
wx-config doesn't include -std=c++11 in its output currently and it's not
clear whether it should (consider c++11 vs gnu++11 or even vs c++14), so add
this compiler option explicitly in C++11 Travis builds.
This allows to do make these steps more complicated, e.g. avoid using apt-get
under non-Linux (and even non-Debian/Ubuntu) platforms.
Also install GTK+ development package explicitly, while it's already available
on the older Travis Ubuntu 12.04 VMs, this is not the case for the newer 14.04
ones.
Make it simpler to enable C++11 support when building wxWidgets, in particular
take care of using the correct standard library under OS X in this case.
Notice that currently we still build the library using C++98 if no C++11
compiler is available, even with this option. We may want to change this to
give an error in such case later instead.
Also skip the check for <type_traits> in configure when C++11 is used, we know
that it's available in this case, so don't waste time checking for it (there
are probably several more checks that could be skipped in C++11 mode too...).
We rely on string literals being of non-const char or wchar_t pointer type for
this code to compile, even if this results in warnings, so we're not
interested in these warnings in the test code itself.
This is not completely true, but the changes in the versions 9 and 10 of g++
ABI don't (seem to?) affect wxWidgets, so allow using later versions of the
compiler for building the code using the libraries created using earlier ones.
