Fix menu event handlers calling order.

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
Pass menu events to the handler in the associated menu bar.

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
Consistently set wxMenuBar parent in all ports.

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
Use correct line numbers in assert failures in event propagation test.

Replace the calls to CheckMenuEvent() helper with ASSERT_MENU_EVENT_RESULT()
macro to allow passing the correct line number to cppunit assertion function,
otherwise the line number of CheckMenuEvent() was always used in case of
failure.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73924 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Add public wxDocManager::GetAnyUsableView().

This method tries to find the current view harder than GetCurrentView() and
always returns a non-NULL view if there are any open documents at all.

This is used by wxDocManager internally to find the view to apply the user
commands to and will also be needed in the upcoming changes outside of
wxDocManager, so just make this method public, as it seems that it could be
useful in user code too, especially if we could use some better fallback than
the first opened document (e.g. the last document the user interacted with
would be better).

This also clarifies the confusion between GetCurrentView() and GetActiveView(),
see #13296.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73925 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Factor out functions dealing with menus in the event propagation test.

No real changes, just refactor the code to allow testing for menu events in
other frames too.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73926 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Forward events to active child at MSW, not wx, level in wxMDIParentFrame.

We want to handle menu (and toolbar) events in the active MDI child before
handling them in the parent frame itself and the existing code achieved this
by forwarding wxEVT_MENU events at wx event processing level to the active
child. However this was not enough as the underlying MSW WM_COMMAND message
was still sent to the parent frame only and this could result in wx event not
being generated at all if the parent frame had a disabled menu item with the
same ID as (an enabled) item in the child frame, see #14314.

So forward WM_COMMAND directly to ensure that the correct window gets the
event in the first place. And this makes wxEVT_MENU forwarding in TryBefore()
unnecessary.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73927 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Fix event handling order in doc/view framework.

Ensure that the events are always (provided there is an open document)
processed in the following order:

1. wxDocument
2. wxView
3. wxDocManager
4. wxDocChildFrame
5. wxDocParentFrame
6. wxApp

Do this by forwarding the events from wxDocParentFrame to wxDocChildFrame
first and forward them from there to wxDocManager which -- and this part
remains unchanged -- in turn forwards them to the active wxView which finally
forwards them to wxDocument. This requires another condition in the event
handling code as we still must forward from wxDocParentFrame to wxDocManager
itself if there are no active children at all, but this is the only way to
have the same event order in all cases, whether the event is originally
received by wxDocChildFrame or wxDocParentFrame.

Document this and add a unit test verifying that things indeed work like this.

See #14314.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73928 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use wxWindow::Refresh() instead of artificial wxPaintEvent in the test.

This fixes memory leaks under wxMSW: as the test code didn't (and couldn't)
call wxPaintDCImpl::EndPaint(), there was a leak for each wxPaintEvent
generated in it since the changes to wxDC caching in r72938.

It's also preferable because it uses public API instead of feeding events to
the window which is not documented to work.

Unfortunately even using Refresh() still doesn't allow the test to work under
wxOSX.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73929 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775