giuseppe.dangelo at kdab.com
Wed Apr 14 18:31:59 CEST 2021
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
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.
Giuseppe D'Angelo | giuseppe.dangelo at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4329 bytes
Desc: Firma crittografica S/MIME
More information about the Interest