QIODevice::bytesWritten ( qint64 bytes ) signal not working



  • Hi,

    In my program i want the bytesWritten signal to be emitted once the specified bytes have been read into the IO device, but i checked this many times, bytesWritten signal is not getting emitted.

    please help me with this....

    thanx in advance...


  • Moderators

    I have not checked the docs, but I naively would expect a bytesWritten() signal when the QIODevice has written some data (to a file, socket, whatever), not when bytes were read.



  • thanx for your reply and sorry for my mistake...

    i want bytesWritten(qint64 bytes ) signal to be emitted whenever QIODevice is having "bytes" data in it, but this signal is not emitted...


  • Moderators

    As tobias Hunger has already suggested "bytesWritten":http://developer.qt.nokia.com/doc/qt-4.8/qiodevice.html#bytesWritten sais :
    [quote]This signal is emitted every time a payload of data has been written to the device. [/quote]
    you may use the "readyRead signal":http://developer.qt.nokia.com/doc/qt-4.8/qiodevice.html#readyRead and check the number of byte available with "bytesAvailable":http://developer.qt.nokia.com/doc/qt-4.8/qiodevice.html#bytesAvailable



  • hey koahnig thanx for your reply,

    currently i am using readyRead() signal but now i want to replace it by bytesWritten() signal, but it seems to me that bytesWritten() signal is not working...

    can u please tell me wat could be the problem...



  • Just a wild guess: you are not writing any data to the device, and hence, the bytesWritten signal is never emitted.



  • Why on earth do you want to replace it? That two signals serve two totally different purposes - of course it does not work! How come that you expect that this could work?


  • Moderators

    the problem is the direction of data.
    the readyRead signal will be emitted when data is available to read during input of data.
    the bytesWritten will be emitted when data has been written to device during output of data.



  • for of all thanx to all for spending ur precious time with my problem.

    @ andre: the data is written into the device continously.

    @volker: i want to replace readyRead() signal because, readyRead() signal gives me random amount of data i.e whenever this signal is emitted it doesn't always give me same amount of data.

    So i wanted to replace it by bytesWritten() signal which will be emitted only when the specified amount of data is there in the IODevice.

    @koahnig: if the problem is about the direction of data, then i have no other option than to stick with the readRead() signal... :(

    thanx...



  • The data is written by whom? By your own application? In that case, you can use bytesWritten(). However, even in this case, the number of bytes written is out of your control. However, it seems that you're using readyRead() now, and that would mean that you are reading now.

    I'm really not sure what you want to achieve... Why is it an issue that you don't get a constant number of bytes from readyRead?



  • basically what i want is, every time when i get this signal ( bytesWritten() or readyRead() ) , i want constatnt number of bytes to be available to read...
    but this is not happening when i used readyRead(), thats why i was trying to use bytesWritten() signal, but even after using bytesWritten() signal, if i am not able to control the number of bytes then i think i have to use readyRead only, i have no other option...

    thanx andre...



  • No chance, with neither of the methods will give you such a guarantee. If you're reading, you cannot just use the bytesWritten signal because you think it suits your fancy. It just doesn't work that way.

    For your actual issue, I would probably just:

    ignore the signal if the number is lower than what I'd like, and

    just read the wanted number of bytes if the number is equal or higher than what I'd like



  • thanx andre...

    if that is the case then i will use readyRead() only...

    thanx again for clearing my doubt....


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.