@SimonSchroeder said in QByteArray to QVariantMap while conserving numerical type:

In that case you need to specify some formatting to make sure the number is written out in a way that makes it clear it is floating point.

I don't follow you here. How would any kind of formatting of the number at sender side make any difference to the result received at the receiver side using a JSON parser to read it which will return a "numeric"/QJsonValue::Type::Double? Other than sending it is a string type and doing the numeric conversion at receiver side, which is quite different.

HI @R-P-H ,

Besides converting the QByteArray to a QString, how would I extract the value if I added {} to the QByteArray ...

As long as the QByteArray contains a valid JSON value, you can either wrap it in [ and ] to make it a JSON array, or { "key": and } to make it a JSON object. If wrapping in an array, you would then fetch the first array item to get the original JSON value. Of if wrapping in an object, fetch the value corresponding to the key you used in the wrapper.

Here's a complete example:

const QByteArray json{ "\"My Value\" "}; qDebug().noquote() << "input " << json; qDebug().noquote() << "parse-as-is " << QJsonDocument::fromJson(json); // Will fail. const QJsonDocument arrayDoc = QJsonDocument::fromJson("[" + json + "]"); qDebug().noquote() << "wrapped-in-array " << arrayDoc; qDebug().noquote() << "unwrapped-array " << arrayDoc.array().at(0); const QJsonDocument objectDoc = QJsonDocument::fromJson("{ \"value\": " + json + "}"); qDebug().noquote() << "wrapped-in-object " << objectDoc; qDebug().noquote() << "unwrapped-object " << objectDoc.object().value(QStringLiteral("value"));

Which outputs:

input "My Value" parse-as-is QJsonDocument() wrapped-in-array QJsonDocument(["My Value"]) unwrapped-array QJsonValue(string, My Value) wrapped-in-object QJsonDocument({"value":"My Value"}) unwrapped-object QJsonValue(string, My Value)

Cheers.

I made a rudimentary solution for the problem.

//Read data to QString with a known length void readDataQString(QDataStream &ds, QString &str, uint length) { QByteArray buffer(length,Qt::Uninitialized); ds.readRawData(buffer.data(),length); str = QString(buffer); qInfo() << str; } //Write data from QString without length info void writeDataQString(QDataStream &ds, QString &str) { QByteArray ab = str.toUtf8(); for(int i = 0; i < ab.size(); ++i) { quint8 int_8 = static_cast<quint8>(ab.at(i)); ds << int_8; } QBuffer *internalBuffer = qobject_cast<QBuffer*>(ds.device()); QByteArray ba = internalBuffer->buffer(); qInfo() << ba.toHex(':'); }

I hope this works for everyone.

@UvQtcYZJuD7J5VW7 said in QByteArray to LabVIEW Byte Array conversion:

I need to include Labview extcode.h

Yes, that's right.

and when I include it, I get errors about my compiler (platdefines.h doens't recognize my compiler when I'm in Qt Creator).

Then you just need to address the error.

If you use MSVC, it will work fine out-of-the-box.

If you want to use MinGW, you can modify platdefines.h and add these 2 lines to define your compiler:

... #elif defined(__GNUC__) // <-- Add this #define Compiler kGCC // <-- Add this #else #error "We don't know the Compiler" #endif

@Sina-Ranjkesh-zade said in Converting QByteArray to QString:

For "standard input" if you mean input arguments of the process, I got this error:

No, I meant standard input. That is , the python program reads from a terminal and accepts input just as if you typed it (except it is the Qt program sending that input). The Qt program can send a command to the python program, send the data it needs, and read the result (if there is one) back on the python program's standard output. Or you can used shared memory, or a socket, or files, or do whatever the python program is doing in the Qt program...

@JonB I can live with one pair of new/delete :)

Thank you all who contributed and especially to @Christian-Ehrlicher for pointing me out the obvious.

I fixed my problem:

with a qDebug of lenght I have:

data.length() lenght 136 2730 740 1364 1326 1366 414 1364 208 1366 458 1364

As you can see they are not the same so, with this code, my problem is fixed:

void Window::processAudioFrame(QByteArray data){ const short* result = (short *)data.constData(); for (int i=0; i < data.length()/2; i ++ ){ ui->soundView->pushSoundLevel(result[i]); } }

@jsulm I just now noticed this when I was debugging the code and was about to update here but I see u have already answered it. Thanks

I gained insight from all your posts. It turns out that simply correcting the line length sorted the problem, thank you.

@JonB Thanks. I didn't know about those links. they look promising. This whole networking stuff is really new to me

@Christian-Ehrlicher Thanks. So for large data, I guess QWebSocket::binaryFrameReceived() is the correct way

Maybe that QByteArray is the culprit, you could try rewrite into more vanilla standard:

... { QByteArray block; QBuffer buffer(&block); buffer.open(QIODevice::WriteOnly); QDataStream out(&buffer); ...

at least you would expose more stuff to the debugger :-)

@jsulm said in QDataStream an openCV::mat serialisation...:

@Dariusz What is stream here? Is it QDataStream?
"Any idea what did I mess up with this ?" - well, what is not working?

Yep :- )

I think I might "got it". Naturally 5 min after asking question... elemSize1() return incorrect number of channels. Looks like I need elemSize() instead. still testing.

Yep it was wrong element number.

Hope it helps other "serializers" out here : -)

@Dariusz Simply seek to the position where you want to read and then read the amount of bytes you need.
https://doc.qt.io/qt-5/qfiledevice.html#seek
https://doc.qt.io/qt-5/qiodevice.html#read-1

You can seek to the beginning of the file if you decide to read whole file.

@Christian-Ehrlicher Thanks, that was exactly my problem.

@JealousFish Yes,
In Qt Creator is called “Build Directory”, where file .o are created and where you find your application.
In the past I had the same issue, when I deleted the build folder the problem disappeared.
Sometimes, when compiler failed and the code seems ok, I delete the builder folder and the problem disappears.
I think, but it is only my idea, when this happens some files .o are locked, perhaps because I stopped the previous compile.

Ok got it solved.

Since my widgets were a little "complex" as I had QDockWidget, that had QMainWindow, so that each dock widget could house sub dock widgets. The native QT storeGeometry did not work for DockWidgets and I needed storeState/restoreState, so I subclassed my widgets to work on states of my mainWindows instead of geometries. In any case it all works now.

Hope this helps if any1 else tries it.

@Paul-Colby Thanks

i myself did something like this :)

QVariantMap json_map; const QJsonDocument doc = QJsonDocument::fromJson(output); qDebug().noquote() << doc; qDebug().noquote() << doc.array(); foreach (auto value, doc.array()) { qDebug().noquote() << value; qDebug().noquote() << value.toObject(); qDebug().noquote() << value.toObject().value("name"); json_map["name"] = value.toObject().value("name").toString(); json_map["installed"] = value.toObject().value("installed").toBool(); json_map["id"] = value.toObject().value("id").toString(); json_map["filename"] = value.toObject().value("filename").toString(); }