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
