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
Call wxMDIChildFrame::Activate() explicitly as the behaviour was different
under MSW (where the activation happened too late for the test) and GTK where
the child did become active because of the hacks in place to ensure it.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74355 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Fix the bug with multiple wxContextMenuEvent being generated for a single
WM_CONTEXTMENU without breaking context menus for wxTextCtrl (and all the
other native controls). Do this by ensuring that WM_CONTEXTMENU is still
passed to DefWindowProc() if we don't process it instead of just being eaten
completely in any case.
Also add a unit test checking for this bug to ensure it stays fixed.
See #13683.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74329 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
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
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
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
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
After the recent changes to the event processing logic, forwarding an event
from one event handler to another one stopped working correctly because the
per-event "process here only" flag prevented it from following the event
handler chain after forwarding. This notably broke keyboard navigation in
wxComboCtrl under MSW in wx itself and probably quite a few of other things in
user code.
Fix this by replacing the boolean flag with a pointer to the handler to which
the processing of this event should be restricted. This allows the full
processing to still take place if an event is forwarded to another handler.
So wxEvent::ShouldProcessHereOnly() is now called ShouldProcessOnlyIn() and
takes a wxEvtHandler parameter.
This made appear a problem in wxScrollHelperEvtHandler code that was hidden by
the bug above: the events were still processed multiple times in it. To fix
this, also add wxEvent::DidntHonourProcessOnlyIn() and take it into account in
the base class code. Did I mention that wxScrollHelperEvtHandler must die?
Add another unit test checking that forwarding works correctly.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64464 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Calling ProcessEventLocally() didn't work because the command events were not
propagated to the parent window any more, breaking a lot of things including
wxDataViewCtrl event generation in the generic version. So do restore
ProcessEvent() call but use it on the next handler (i.e. the window itself)
and not this one now. This still results in some duplicate calls but at least
the events should be passed everywhere where they are expected to arrive.
wxScrollHelperEvtHandler must die.
Closes#12078.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64370 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use ProcessEventLocally() added in r64261 (which was probably the one to break
this) to forward event to the window itself instead of ProcessEvent() in
wxScrollHelperEvtHandler::ProcessEvent() implementation. Calling ProcessEvent()
didn't work any more in a case when another event handler was pushed on a
wxScrolledWindow: in this case the EVT_SIZE and EVT_PAINT handlers defined in
the window itself were not called at all any more.
Add a unit test checking for the even more tortuous than usual event
processing path in this particular case.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64358 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
from public to protected. Adapt wxWidgets code and wxWidgets samples to always use wxWindow::GetEventHandler()
when calling such functions on a wxWindow rather than directly using wxWindow::ProcessEvent, etc.
This enables correct event dispatching to the event handlers which have been pushed (with PushEventHandler) on the
windows.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@58381 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
