TQEventLoop allows the application programmer to have more control over event delivery. Programs that perform long operations can call either processOneEvent() or processEvents() with various ProcessEvent values OR'ed together to control which events should be delivered.
TQEventLoop also allows the integration of an external event loop with the TQt event loop. The Motif Extension included with TQt includes a reimplementation of TQEventLoop for merging TQt and Motif events together.
Creates a TQEventLoop object, this object becomes the global event loop object. There can only be one event loop object. The TQEventLoop is usually constructed by calling QApplication::eventLoop(). To create your own event loop object create it before you instantiate the QApplication object.
Note: This function is only useful on systems where \fCselect()\fR is used to block the eventloop. On Windows, this function always returns 0. On MacOS X, this function always returns 0 when the GUI is enabled. On MacOS X, this function returns the documented value when the GUI is disabled.
Enters the main event loop and waits until exit() is called, and returns the value that was set to exit().
.PP
It is necessary to call this function to start event handling. The main event loop receives events from the window system and dispatches these to the application widgets.
.PP
Generally speaking, no user interaction can take place before calling exec(). As a special case, modal widgets like QMessageBox can be used before calling exec(), because modal widgets call exec() to start a local event loop.
To make your application perform idle processing, i.e. executing a special function whenever there are no pending events, use a TQTimer with 0 timeout. More advanced idle processing schemes can be achieved using processEvents().
Process pending events that match \fIflags\fR for a maximum of \fImaxTime\fR milliseconds, or until there are no more events to process, which ever is shorter.
.PP
This function is especially useful if you have a long running operation and want to show its progress without allowing user input, i.e. by using the ExcludeUserInput flag.
.PP
NOTE: This function will not process events continuously; it returns after all available events are processed.
.PP
NOTE: Specifying the WaitForMore flag makes no sense and will be ignored.
This is an overloaded member function, provided for convenience. It behaves essentially like the above function.
.PP
Processes pending events that match \fIflags\fR until there are no more events to process.
.PP
This function is especially useful if you have a long running operation and want to show its progress without allowing user input, i.e. by using the ExcludeUserInput flag.
.PP
If the WaitForMore flag is set in \fIflags\fR, the behavior of this function is as follows:
.IP
.TP
If events are available, this function returns after processing them.
.IP
.TP
If no events are available, this function will wait until more are available and return after processing newly available events.
.IP
.PP
If the WaitForMore flag is \fInot\fR set in \fIflags\fR, and no events are available, this function will return immediately.
.PP
NOTE: This function will not process events continuously; it returns after all available events are processed.
.PP
This function returns TRUE if an event was processed; otherwise it returns FALSE.
Registers \fInotifier\fR with the event loop. Subclasses need to reimplement this method to tie a socket notifier into another event loop. Reimplementations \fIMUST\fR call the base implementation.
Note: This function is only useful on systems where \fCselect()\fR is used to block the eventloop. On Windows, this function always returns -1. On MacOS X, this function always returns -1 when the GUI is enabled. On MacOS X, this function returns the documented value when the GUI is disabled.
Unregisters \fInotifier\fR from the event loop. Subclasses need to reimplement this method to tie a socket notifier into another event loop. Reimplementations \fIMUST\fR call the base implementation.
