add wxAppConsoleBase::DeletePendingEvents and wxEvtHandler::DeletePendingEvents.

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
This commit is contained in:
Francesco Montorsi
2009-03-08 12:58:24 +00:00
parent db034c5228
commit cae9e7b169
6 changed files with 97 additions and 13 deletions

View File

@@ -533,7 +533,32 @@ public:
@see wxWindow::HandleWindowEvent
*/
bool SafelyProcessEvent(wxEvent& event);
/**
Processes the pending events previously queued using QueueEvent() or
AddPendingEvent(); you must call this function only if you are sure
there are pending events for this handler, otherwise a @c wxCHECK
will fail.
The real processing still happens in ProcessEvent() which is called by this
function.
Note that this function needs a valid application object (see
wxAppConsole::GetInstance()) because wxApp holds the list of the event
handlers with pending events and this function manipulates that list.
*/
void ProcessPendingEvents();
/**
Deletes all events queued on this event handler using QueueEvent() or
AddPendingEvent().
Use with care because the events which are deleted are (obviously) not
processed and this may have unwanted consequences (e.g. user actions events
will be lost).
*/
void DeletePendingEvents();
/**
Searches the event table, executing an event handler function if an appropriate
one is found.
@@ -555,6 +580,9 @@ public:
If a suitable function is called but calls wxEvent::Skip, this
function will fail, and searching will continue.
@todo this function in the header is listed as an "implementation only" function;
are we sure we want to document it?
@see ProcessEvent()
*/