Writing binary data from QByteArray to windows registry using QSettings
-
How do you write a mac address from a text box in the form of 01:23:45:67:89:ab to a key in the windows registry which is of type REG_BINARY?
This makes the requirement to take the mac address and use setValue to write to the registry key. Getting it in the form of the QByteArray isn't the problem. It's when I send it down, the type is changed and the value changed as well.
@
QByteArray ba = QByteArray::fromHex(ui->lineEditMacAddress->text().toLatin1());
settings.setValue(MacAddr, ba);
@After this the type changes from REG_BINARY to REG_SZ (string). The data gets corrupted too and looks like the following:
@
@ByteArray(#Eg«)
@rather than the original. Which is a array of each number without the separator.
-
[quote author="alexisdm" date="1395350111"]You can't write the content of a QByteArray by itself as REG_BINARY to the registry with QSettings, it will always add "@ByteArray()".
You will have to use the WinAPI.
[/quote]
...and yet I can read REG_BINARY type data to a QByteArray without issue?
Hmmm.
-
Actually, reading might not always work, because QSettings reads the REG_BINARY as a unicode string, when it isn't inside a "@ByteArray(x)", and is then converted to a QByteArray by QVariant.
See https://bugreports.qt-project.org/browse/QTBUG-3775
and https://bugreports.qt-project.org/browse/QTBUG-98And when writing it only uses REG_BINARY for strings if there is a null unicode character in it.
-
OK,
I don't know if the claim of "might not always work" is proven - at least for reading. It does in fact work consistently for reading and it was documented as such even in QTBUG-98 which you linked. QTBUG-3775 deals with reading un-even number of bytes and my application of it is always a fixed number of bytes.Still, it is at least an annoyance that QSettings is limited this way in Qt 5, especially when it was remarked to be "fixed" in Qt 5 in QTBUG-98.
At least the Win API's still work :)
-
[quote author="astodolski" date="1395410596"]I don't know if the claim of "might not always work" is proven - at least for reading. It does in fact work consistently for reading [/quote]
If you want some examples, it won't work if the data starts with:- a utf BOM mark (0xfffe or 0xfeff), these first two bytes will be removed from the QByteArray output, and each following 16-bit word might be swapped depending on the mark (e.g. 0xfeff01020304 is read as 0x02010403),
- "@@" (in utf-16 which should be 0x40004000) the first "@" will be removed, because "@XXX(x)" is used to specify a type name.
But these are highly improbable MAC addresses :)