+// TODO: implement wxEventLoopSource for MSW (it should wrap a HANDLE and be
+// monitored using MsgWaitForMultipleObjects())
+#if defined(__WXOSX__) || (defined(__UNIX__) && !defined(__WXMSW__))
+ #define wxUSE_EVENTLOOP_SOURCE 1
+#else
+ #define wxUSE_EVENTLOOP_SOURCE 0
+#endif
+
+#if wxUSE_EVENTLOOP_SOURCE
+ class wxEventLoopSource;
+ class wxEventLoopSourceHandler;
+#endif
+
+/*
+ NOTE ABOUT wxEventLoopBase::YieldFor LOGIC
+ ------------------------------------------
+
+ The YieldFor() function helps to avoid re-entrancy problems and problems
+ caused by out-of-order event processing
+ (see "wxYield-like problems" and "wxProgressDialog+threading BUG" wx-dev threads).
+
+ The logic behind YieldFor() is simple: it analyzes the queue of the native
+ events generated by the underlying GUI toolkit and picks out and processes
+ only those matching the given mask.
+
+ It's important to note that YieldFor() is used to selectively process the
+ events generated by the NATIVE toolkit.
+ Events syntethized by wxWidgets code or by user code are instead selectively
+ processed thanks to the logic built into wxEvtHandler::ProcessPendingEvents().
+ In fact, when wxEvtHandler::ProcessPendingEvents gets called from inside a
+ YieldFor() call, wxEventLoopBase::IsEventAllowedInsideYield is used to decide
+ if the pending events for that event handler can be processed.
+ If all the pending events associated with that event handler result as "not processable",
+ the event handler "delays" itself calling wxEventLoopBase::DelayPendingEventHandler
+ (so it's moved: m_handlersWithPendingEvents => m_handlersWithPendingDelayedEvents).
+ Last, wxEventLoopBase::ProcessPendingEvents() before exiting moves the delayed
+ event handlers back into the list of handlers with pending events
+ (m_handlersWithPendingDelayedEvents => m_handlersWithPendingEvents) so that
+ a later call to ProcessPendingEvents() (possibly outside the YieldFor() call)
+ will process all pending events as usual.
+*/
+