Il 14/04/21 16:15, Jérôme Godbout ha scritto:
Yeah that would be a pain, but if it work you can try to reduce the QVariant usage to a minimum from that point.1. QVariantMap 2. QMap<QVariant, QVariant> 3. QMap<QString, QVariant> 4. QMap<QString, QVariantList> 5. QMap<QString, QList<QVariant>> 6. QMap<QString, QList<QString>>See up to where you can reach before it fail, it will tell you which data type is not working for the type mapping. If they all succeed, then something might be wrong with the QList<QString> or QStringList if you prefer. Maybe the exposed type doesn’t handle the typedef properly when nested.
A mandatory note: a QVariant can hold _any_ data type (even application-defined ones). That doesn't mean you can send a QVariant over to JS and expect to magically manipulate its contents from over there. Only QVariants with _specific_ contents work.
(For comparison, in QML, all the ones with unsupported content become a `var` blob, that you can only copy around and eventually pass back to C++; but they're unusable from QML itself).
So although you can store a QMap<QString, QStringList> in a QVariant, that doesn't mean it magically works because of the wrapping.
If the docs are not conclusive about which datatypes work and under which conditions, do the simple tests suggested above (exposing progressively more and more "complicated" types); that should quickly help figuring out what is actually supported and what not.
HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
