In following code snippets, I try to transfer an ArrayBuffer
from QML to a C++ handler, where it is supposed to get converted into a QByteArray
. This is working in QT 6.5.1 but stopped working in 6.5.2.
main.cpp
#include <QGuiApplication>
#include <QQmlApplicationEngine>
#include <QQuickItem>
#include "ComboBoxHandler.h"
int main(int argc, char *argv[])
{
QGuiApplication app(argc, argv);
// register the class with the QML engine
auto handler = new ComboBoxHandler();
qmlRegisterSingletonInstance("ComboBoxHandler", 1, 0, "ComboBoxHandler", handler);
QQmlApplicationEngine engine;
QObject::connect(&engine, &QQmlApplicationEngine::objectCreationFailed,
&app, []() { QCoreApplication::exit(-1); },
Qt::QueuedConnection);
const QUrl url(u"qrc:/TestBench/main.qml"_qs);
engine.load(url);
return app.exec();
}
main.qml
import QtQuick
import QtQuick.Window
import QtQuick.Controls
import ComboBoxHandler
ApplicationWindow
{
id: mainWindow
width: 600
height: 400
visible: true
Button {
text: "test"
onClicked: {
// fill in some data into the ArrayBuffer
let data = [];
for (let i = 0; i < 10; ++i) {
data.push(i);
}
// send ArrayBuffer to handler
ComboBoxHandler.onItemChanged(data)
}
}
}
ComboBoxHandler.h
#pragma once
#include <QObject>
#include <QDebug>
class ComboBoxHandler: public QObject {
Q_OBJECT
public slots:
void onItemChanged(const QByteArray& newValue) {
// I would expect the data here.
// works in QT 6.5.1 and stopped working in 6.5.2
qDebug() << "Value: " << newValue;
}
};
Can anyone confirm, that this is not working in 6.5.2?
Has anyone a fix or a workaround for this?
Is this a QT regression bug?
It sounds like a bug to me, though you never actually define what “not working” means. Does newValue have anything in it at all?
Yes. newValue is empty when running with 6.5.2. With 6.5.1 the QByteArray contains the elements.
In QML/JS the thing you’re declaring is a QVariantList not an ArrayBuffer. If you set your C++ type to QVariant you can confirm whether you’re getting either a QVariantList or an QByteArray and react accordingly to either or both. It’s probably better this way, since, you can coerce/cast/convert the incoming object and do appropriate conversions.