| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
What is the correct way to figure out whether waitForReadyRead with a return value of "false" is an error or a timeout? Back in Qt3 there was an optional bool pointer that could be passed to the similar function and this could be used but this is missing in Qt4. -- [ signature omitted ]
Brad Pepers wrote: >What is the correct way to figure out whether waitForReadyRead with a >return value of "false" is an error or a timeout? Back in Qt3 there >was an optional bool pointer that could be passed to the similar >function and this could be used but this is missing in Qt4. I see the problem. What is missing is an error() virtual in QIODevice. I've been missing it too. If you know what your device is, you may figure out if it has disconnected from the underlying stream (i.e., socket closed, process finished). In Qt 4.4, it will have emitted the readChannelFinished() signal. In Qt 4.4 as well, if you read() and the stream is still there, you'll get 0 as the return value. If there was an error, you'll get a -1. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On 2-Mar-08, at 12:55 PM, Thiago Macieira wrote: > Brad Pepers wrote: >> What is the correct way to figure out whether waitForReadyRead with a >> return value of "false" is an error or a timeout? Back in Qt3 there >> was an optional bool pointer that could be passed to the similar >> function and this could be used but this is missing in Qt4. > > I see the problem. What is missing is an error() virtual in QIODevice. > I've been missing it too. > > If you know what your device is, you may figure out if it has > disconnected > from the underlying stream (i.e., socket closed, process finished). > In Qt > 4.4, it will have emitted the readChannelFinished() signal. > > In Qt 4.4 as well, if you read() and the stream is still there, > you'll get > 0 as the return value. If there was an error, you'll get a -1. > So there isn't really a single good way to tell if a waitForReadyRead times out or is successful then? It would have been nice to have that passed in bool pointer like the Qt3 code had. In looking at the source though, it seems like the error() method in QAbstractSocket would be returning SocketTimeoutError in the case of the timeout expiring and some other error if the return from waitForReadyRead is false and its not a timeout. So I should be able to use this right? If this is so, it would be nice to document it in the waitForReadyRead method (and any of the other waitFor... methods where it is true) so that its plain that you can actually know whether the timeout expired or not. -- [ signature omitted ]
Brad Pepers wrote: >So there isn't really a single good way to tell if a waitForReadyRead >times out or is successful then? It would have been nice to have that >passed in bool pointer like the Qt3 code had. Then we have to ask: what use would it be for you to know if it timed out instead of errorring out? What actions would you take differently? >In looking at the source though, it seems like the error() method in >QAbstractSocket would be returning SocketTimeoutError in the case of >the timeout expiring and some other error if the return from >waitForReadyRead is false and its not a timeout. So I should be able >to use this right? Correct. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.