A possible bug with QImage, QDataStream and QByteArray?
-
I noticed something very strange, this code works as expected:
QByteArray data; QBuffer buff(&data); QDataStream out(&buff); out << img; qDebug() << QImage::fromData(data);
But it gives a warning about the IODevice not being open.
If I manually
buff.open()
,fromData()
produces a null image again.Without explicitly opening, the openMode() is automatically set to
Unbuffered | WriteOnly
and it works, if I open() it explicitly toUnbuffered | WriteOnly
it doesn't work. There is still data in the byte array, butfromData()
fails.Any ideas why is that?
-
@iter
Most people answering in this forum do that on their spare time. They are trying to be helpful and suggesting sometimes options which may not work. They cannot test out everything beforehand. And why should they?Opening with WriteOnly and trying to read later on does not really sound correct. Did you try to open with ReadWrite mode?
How did you find out that the default openMode is "Unbuffered | WriteOnly"? Respectively, where did you read this?
-
@iter
Most people answering in this forum do that on their spare time. They are trying to be helpful and suggesting sometimes options which may not work. They cannot test out everything beforehand. And why should they?Opening with WriteOnly and trying to read later on does not really sound correct. Did you try to open with ReadWrite mode?
How did you find out that the default openMode is "Unbuffered | WriteOnly"? Respectively, where did you read this?
"They are trying to be helpful and suggesting sometimes options which may not work"
I think if one is actually concerned with helping, that person will spare the 30 seconds needed to verify the correctness of an answer. Making random assumptions isn't much help... And it is not like it is something complex to test, it is few self-contained lines of code. And in the case of an eventual bug, I think it is only the appropriate thing to actually do the test in order to reproduce it.
"Did you try to open with ReadWrite mode?"
Yes. It does not help, besides there is no reading from the datastream/iodevice in that case...
"How did you find out that the default openMode is "Unbuffered | WriteOnly"? "
I checked using that very method. And I did not say it is a "default" - it is what automatically happens if the IODevice is not opened explicitly and written to. Plus the warning that it is not open. Since the "automatic opening" produces a working example and the explicit does not, I suspect the issue has something to do with that.
And just in case it wasn't clear from the context,
close()
does not help either. -
"They are trying to be helpful and suggesting sometimes options which may not work"
I think if one is actually concerned with helping, that person will spare the 30 seconds needed to verify the correctness of an answer. Making random assumptions isn't much help... And it is not like it is something complex to test, it is few self-contained lines of code. And in the case of an eventual bug, I think it is only the appropriate thing to actually do the test in order to reproduce it.
"Did you try to open with ReadWrite mode?"
Yes. It does not help, besides there is no reading from the datastream/iodevice in that case...
"How did you find out that the default openMode is "Unbuffered | WriteOnly"? "
I checked using that very method. And I did not say it is a "default" - it is what automatically happens if the IODevice is not opened explicitly and written to. Plus the warning that it is not open. Since the "automatic opening" produces a working example and the explicit does not, I suspect the issue has something to do with that.
And just in case it wasn't clear from the context,
close()
does not help either. -
"They are trying to be helpful and suggesting sometimes options which may not work"
I think if one is actually concerned with helping, that person will spare the 30 seconds needed to verify the correctness of an answer. Making random assumptions isn't much help... And it is not like it is something complex to test, it is few self-contained lines of code. And in the case of an eventual bug, I think it is only the appropriate thing to actually do the test in order to reproduce it.
"Did you try to open with ReadWrite mode?"
Yes. It does not help, besides there is no reading from the datastream/iodevice in that case...
"How did you find out that the default openMode is "Unbuffered | WriteOnly"? "
I checked using that very method. And I did not say it is a "default" - it is what automatically happens if the IODevice is not opened explicitly and written to. Plus the warning that it is not open. Since the "automatic opening" produces a working example and the explicit does not, I suspect the issue has something to do with that.
And just in case it wasn't clear from the context,
close()
does not help either.I gotta echo what is being said by koahnig... If you post in a forum asking for help you cannot expect people making suggestions to have taken the time to fully code up, document and prove a simple suggestion to your problem!
As far as the "correctness" of their answer I think it serves to state that if it is something you have not tried or perhaps thought of yourself then how can you judge it is incorrect? A suggestion is just that... a suggestion. It is not a guarantee of correctness and that it will solve your problem.
This stuff is complex. I recently was dealing with a QTcpSocket and all the documentation says to connect signals up in a specific way. It didn't work and I followed the documentation exactly. What was different was where my instance was. I found that by moving where I connected the signals everything started to work. My point to posting this is that it doesn't make the documentation or suggestion "wrong" because it doesn't work in your code.
I have had good luck reporting bugs. Usually someone checks it out fairly quickly but they are under no obligation to do so. Are you a community edition or commercial user? If you are a community edition user keep in mind you did not pay for support or bug fixes so consider that all the support you get here or on JIRA is coming to you free of charge.
If you are a commercial user then you have your own dedicated support channel and you should be asking for help there.