For this, it cannot derive from wxCommandEvent. Extracted the bits
from wxCommandEvent useful for passing data between threads into
wxEventBasicPayloadMixin helper class shared by both.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68076 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Failing to send wxEVT_UPDATE_UI to hidden windows made it impossible to show
them from their update UI handler which was totally unexpected as the
documented wxUpdateUIEvent::Show() method could never be used.
Do send these events to the hidden windows themselves but avoid sending the
update UI events to the children of hidden windows as this is really useless
because any change of their state wouldn't be seen by the user anyhow (even if
the child is shown, it would still remain hidden until its parent is) and
would just waste time processing a lot of needless events.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67541 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This event is sent by wxMSW after the default handling of WM_CHAR has taken
place. It can be used to define an event handler triggered by key presses and
having access to the new value of the control, updated to take the last key
press into account.
This event will be used by auto-completion implementation for wxMSW only for
now.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67512 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Applied patch by snowleopard2 fixing a bunch of typos such as misspellings and double words in the documentation. Combined the patch with some local queued typos waiting to be committed as well as adding new typo fixes inspired by the patch.
Function names with American spelling were not changed nor was third-party code touched. The only code changes involve some changes in strings that are translated ("Can not" -> "Cannot").
Closes#13063 (again).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67280 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxKeyEvent::GetKeyCode() and GetUnicodeKey() return 0 to indicate that the key
code or Unicode character is not available, give symbolic name to this 0 to
make the code using these methods more clear.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65521 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Call pre-processing hooks for each of the handlers in the chain and not only
the first one. This ensures that a validator (which is invoked during the
pre-processing stage) of a window is used even if a window has an event
handler pushed on top of it.
Closes#12177.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65006 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use wxDELETE[A]() functions which automatically NULL out their arguments after
deleting them instead of doing it manually.
Closes#9685.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64656 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is a further complication to the event handling code which aims to handle
correctly the case of wxScrollHelperEvtHandler which doesn't respect the
request to process events only in it but always passes it to the next handler
in the chain itself while still returning the correct value from
ProcessEvent() itself to avoid breaking code that relies on it, like the
background painting code in wxHtmlWindow.
This replaces the change of r64495 and does return true from DoTryChain() in
wxScrollHelperEvtHandler case but sets the "skipped" flag in the event itself
to indicate that it wasn't really processed and ProcessEvent() now checks it
after calling ProcessEventLocally() and returns the correct value
appropriately.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64510 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Correct the return value when an event handler didn't honour "process only in
this handler" flag: we shouldn't pass the event to the further handlers in
this case but we shouldn't return true neither as the event wasn't really
processed.
This corrects background painting of wxHtmlWindow broken by previous changes.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64495 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
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
