class QIOManager

Public Methods

•  QIOManager ()
•  ~QIOManager ()
• void  processOneEvent (bool blocking)
• void  run ()
• void  terminate ()
• void  watchFD (int fd, int types, IONotify *notify)
• void  remove (IONotify *notify, int types)
• void  addTimer (int milliseconds, TimeNotify *notify)
• void  removeTimer (TimeNotify *notify)
• void  setBlocking (bool blocking)
• bool  blocking ()

Protected Methods

• void  dispatch (QIOWatch *ioWatch)
• void  dispatch (QTimeWatch *timeWatch)

Protected Members

• friend class QIOWatch
• friend class QTimeWatch
• std::list<QIOWatch *> fdList
• std::list<QTimeWatch *> timeList

Detailed Description

QIOManager performs MCOP I/O inside the Qt event loop. This way, you will be able to receive requests and notifications inside Qt application. The usual way to set it up is:

 KApplication app(argc, argv);    // as usual

 Arts::QIOManager qiomanager;
 Arts::Dispatcher dispatcher(&qiomanager);
 ...
 return app.exec();               // as usual

[protected]

[protected]

[protected]

[protected]

[protected]

[protected]

Reimplemented from IOManager.

Reimplemented from IOManager.

Reimplemented from IOManager.

Reimplemented from IOManager.

Reimplemented from IOManager.

Reimplemented from IOManager.

Reimplemented from IOManager.

This controls what QIOManager will do while waiting for the result of an MCOP request, the possibilities are:

• block until the request is completed (true)
• open a local event loop (false)

It is much easier to write working and reliable code with blocking enabled, so this is the default. If you disable blocking, you have to deal with the fact that timers, user interaction and similar "unpredictable" things will possibly influence your code in all places where you make a remote MCOP call (which is quite often in MCOP applications).

Query whether blocking is enabled.