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
ProcessEventHere() doesn't have to be public any more now that we have
ProcessEventLocally() which is safe to call from the outside (i.e. doesn't
forget about the chained event handlers and validators).
Still keep this function because it makes the code more modular and also
because we might want to make it virtual for consistency with TryBefore() and
TryAfter() later. Also rename it to TryHere() to make the symmetry with these
functions more manifest.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64264 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This new method can be used to only process the event in this handler or any
handlers connected to it (unlike ProcessEventHere() which doesn't follow the
chain at all), without propagating the event upwards (unlike ProcessEvent()).
Unfortunately implementing this required a field to wxEvent but there doesn't
seem to be any other way to do what we need.
There should be no user-visible changes after this commit, it just paves the
way for the upcoming fixes.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64261 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The event pre-processing hooks associated with the window should be called
only once during the event processing, we don't need to call TryBefore() for
each and every event handler associated with the window too.
This makes the code slightly simpler and faster and shouldn't change the
behaviour of any existing code.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64260 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This allows to test whether a given key belongs to the category of e.g. arrow
keys or navigation keys in a more concise and more readable manner.
Closes#10268.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@61736 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Fix wxAppConsoleBase::Suspend/ResumeProcessingOfPendingEvents: locking the mutex does not prevent wxAppConsoleBase::ProcessPendingEvents from running if the mutex was locked from the main thread!
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@59433 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
- implements YieldFor() with event filtering for wxMSW and wxGTK,
adds TODO markers in other ports;
- replaces wxYield() in GTK's clipboard code with a wxTheApp->YieldFor() call, thus fixing possible reentrancies
(and modifies clipboard sample to test synchronous IsSupported calls)
- replaces wxYieldIfNeeded() calls in wxProgressDialog with wxTheApp->YieldFor() calls, so that it processes only
UI/user-input events, thus fixing the race condition visible in the "thread" sample
- documents the new functions
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@58654 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
not quite up-to-date compilers, to reduce repetitions and to allow using
methods of non-wxEvtHandler-derived classes as event callbacks:
1. Don't rely on compiler ability to deduce template parameter from the type
of a parameter of a function used as another template parameter, at least
MSVC7 can't do this and it's probably not the only one.
2. Do rely on compiler support for partial specialization to make
wxEventFunctorMethod compile for non-wxEvtHandler-derived handlers while
still keeping the old functionality for the wxEvtHandler-derived ones.
3. Don't make any difference between functions and functors, both are callable
objects so use them as such, this allows to fold code for both cases.
4. Avoid the use of dynamic_cast<>.
5. Several naming changes:
a) wxTypedEventType -> wxEventTypeTag (because this is what it is)
b) Subscribe/Unsubscribe -> DoConnect/Disconnect (to follow the usual
convention of public Foo calling private DoFoo and to avoid using up
another name)
c) Derived -> ObjClass (because it's not clear what does Derived mean)
6. Extend the unit test to cover more cases.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@58625 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
