DCOP slot 'char' arg types?, was Re: on the use of char
Richard Dale
Richard_Dale at tipitina.demon.co.uk
Fri Jul 30 11:53:17 BST 2004
On Thursday 29 July 2004 16:03, Richard Dale wrote:
> What's the correct thing to do when sending chars over DCOP?
>
> I send out a char like this:
> *stream << (Q_INT8) stack[i].s_char;
>
> And receive a char like this:
> Q_INT8 temp;
> *stream >> temp;
>
> So should these Q_INT8 types be just 'char' instead, as they can be
> unsigned or signed on different platforms?
I defined a dcop slot like this:
k_dcop:
char foobar(char c);
And it generated this code, which doesn't compile:
bool KBookmarkNotifier::process(const QCString &fun, const QByteArray &data,
QCString& replyType, QByteArray &replyData)
{
if ( fun == KBookmarkNotifier_ftable[0][1] ) { // char foobar(char)
char arg0;
QDataStream arg( data, IO_ReadOnly );
arg >> arg0;
replyType = KBookmarkNotifier_ftable[0][0];
QDataStream _replyStream( replyData, IO_WriteOnly );
_replyStream << foobar(arg0 );
} else {
return DCOPObject::process( fun, data, replyType, replyData );
}
return true;
}
kbookmarknotifier_skel.cc: In member function `virtual bool
KBookmarkNotifier::process(const QCString&, const QByteArray&, QCString&,
QByteArray&)':
kbookmarknotifier_skel.cc:27: no match for `QDataStream& >> char&' operator
/home/duke/src/kde/HEAD/qt-copy/include/qdatastream.h:72: candidates are:
QDataStream& QDataStream::operator>>(Q_INT8&)
Should 'char arg0' be defined as 'Q_INT8 arg0' or 'Q_UINT8 arg0' instead?
-- Richard
More information about the kde-core-devel
mailing list