diff options
Diffstat (limited to 'dcop/HOWTO')
| -rw-r--r-- | dcop/HOWTO | 52 |
1 files changed, 26 insertions, 26 deletions
diff --git a/dcop/HOWTO b/dcop/HOWTO index dedcf97dd..16e60317d 100644 --- a/dcop/HOWTO +++ b/dcop/HOWTO @@ -98,7 +98,7 @@ case: * returns the appId that is actually registered, which _may_ be * different from what you passed */ -appId = client->registerAs(kApp->name()); +appId = client->registerAs(tdeApp->name()); If you never retrieve the DCOPClient pointer from TDEApplication, the object will not be created and thus there will be no memory overhead. @@ -108,11 +108,11 @@ If you wish to attach again you will need to re-register as well. If you only wish to change the ID under which you are registered, simply call DCOPClient::registerAs() with the new name. -KUniqueApplication automatically registers itself to DCOP. If you -are using KUniqueApplication you should not attach or register +TDEUniqueApplication automatically registers itself to DCOP. If you +are using TDEUniqueApplication you should not attach or register yourself, this is already done. The appId is by definition -equal to kapp->name(). You can retrieve the registered DCOP client -by calling kapp->dcopClient(). +equal to tdeApp->name(). You can retrieve the registered DCOP client +by calling tdeApp->dcopClient(). Sending Data to a Remote Application: ------------------------------------- @@ -169,8 +169,8 @@ if (!client->call("someAppId", "fooObject/barObject", "doIt(int)", tqDebug("there was some error using DCOP."); else { QDataStream reply(replyData, IO_ReadOnly); - if (replyType == "QString") { - QString result; + if (replyType == "TQString") { + TQString result; reply >> result; print("the result is: %s",result.latin1()); } else @@ -190,7 +190,7 @@ Receiving Data via DCOP: Currently the only real way to receive data from DCOP is to multiply inherit from the normal class that you are inheriting (usually some -sort of QWidget subclass or QObject) as well as the DCOPObject class. +sort of TQWidget subclass or TQObject) as well as the DCOPObject class. DCOPObject provides one very important method: DCOPObject::process(). This is a pure virtual method that you must implement in order to process DCOP messages that you receive. It takes a function @@ -210,10 +210,10 @@ bool BarObject::process(const QCString &fun, const QByteArray &data, QDataStream arg(data, IO_ReadOnly); int i; // parameter arg >> i; - QString result = self->doIt (i); + TQString result = self->doIt (i); QDataStream reply(replyData, IO_WriteOnly); reply << result; - replyType = "QString"; + replyType = "TQString"; return true; } else { tqDebug("unknown function call to BarObject::process()"); @@ -244,10 +244,10 @@ bool BarObject::process(const QCString &fun, const QByteArray &data, QDataStream arg(data, IO_ReadOnly); int i; // parameter arg >> i; - QString result = self->doIt(i); + TQString result = self->doIt(i); DCOPClientTransaction *myTransaction; - myTransaction = kapp->dcopClient()->beginTransaction(); + myTransaction = tdeApp->dcopClient()->beginTransaction(); // start processing... // Calls slotProcessingDone when finished. @@ -260,13 +260,13 @@ bool BarObject::process(const QCString &fun, const QByteArray &data, } } -slotProcessingDone(DCOPClientTransaction *myTransaction, const QString &result) +slotProcessingDone(DCOPClientTransaction *myTransaction, const TQString &result) { - QCString replyType = "QString"; + QCString replyType = "TQString"; QByteArray replyData; QDataStream reply(replyData, IO_WriteOnly); reply << result; - kapp->dcopClient()->endTransaction( myTransaction, replyType, replyData ); + tdeApp->dcopClient()->endTransaction( myTransaction, replyType, replyData ); } DCOP Signals @@ -315,7 +315,7 @@ that an application that was started via TDELauncher terminates. QByteArray params; QDataStream stream(params, IO_WriteOnly); stream << pid; - kapp->dcopClient()->emitDCOPSignal("clientDied(pid_t)", params); + tdeApp->dcopClient()->emitDCOPSignal("clientDied(pid_t)", params); The task manager of the TDE panel connects to this signal. It uses an anonymous connection (it doesn't require that the signal is being emitted @@ -358,7 +358,7 @@ class MyInterface : virtual public DCOPObject k_dcop: - virtual ASYNC myAsynchronousMethod(QString someParameter) = 0; + virtual ASYNC myAsynchronousMethod(TQString someParameter) = 0; virtual QRect mySynchronousMethod() = 0; }; @@ -385,19 +385,19 @@ but virtual, not pure virtual. Example: -class MyClass: public QObject, virtual public MyInterface +class MyClass: public TQObject, virtual public MyInterface { - Q_OBJECT + TQ_OBJECT public: MyClass(); ~MyClass(); - ASYNC myAsynchronousMethod(QString someParameter); + ASYNC myAsynchronousMethod(TQString someParameter); QRect mySynchronousMethod(); }; -Note: (Qt issue) Remember that if you are inheriting from QObject, you must +Note: (Qt issue) Remember that if you are inheriting from TQObject, you must place it first in the list of inherited classes. In the implementation of your class' ctor, you must explicitly initialize @@ -408,7 +408,7 @@ the interface which your are implementing. Example: MyClass::MyClass() - : QObject(), + : TQObject(), DCOPObject("MyInterface") { // whatever... @@ -419,7 +419,7 @@ exactly the same as you would normally. Example: -void MyClass::myAsynchronousMethod(QString someParameter) +void MyClass::myAsynchronousMethod(TQString someParameter) { tqDebug("myAsyncMethod called with param `" + someParameter + "'"); } @@ -429,9 +429,9 @@ It is not necessary (though very clean) to define an interface as an abstract class of its own, like we did in the example above. We could just as well have defined a k_dcop section directly within MyClass: -class MyClass: public QObject, virtual public DCOPObject +class MyClass: public TQObject, virtual public DCOPObject { - Q_OBJECT + TQ_OBJECT K_DCOP public: @@ -439,7 +439,7 @@ class MyClass: public QObject, virtual public DCOPObject ~MyClass(); k_dcop: - ASYNC myAsynchronousMethod(QString someParameter); + ASYNC myAsynchronousMethod(TQString someParameter); QRect mySynchronousMethod(); }; |