Hi Phil,
I'm not quite sure which change caused the issue, and I believe a
bugreport with a reproducer might shed some light on the issue.
Nevertheless, if you're already using the private QMetaObjectBuilder
API, I would expect that it should work if you build the enum also
dynamically via addEnumerator and then working with the returned
QMetaEnumBuilder.
Kind regards,
Fabian
On 03.10.24 17:52, Phil Thompson via Development wrote:
On 03/10/2024 16:31, Volker Hilsheimer wrote:
On 3 Oct 2024, at 17:07, Phil Thompson via Development
<development@qt-project.org> wrote:
On 03/10/2024 15:44, Thiago Macieira wrote:
On Thursday 3 October 2024 05:06:08 GMT-7 Phil Thompson via
Development wrote:
Yes, that's the change - commenting out the new test fixes the
problem.
I am dynamically building the meta-object. You don't really build an
enum, you just provide a description of it to the meta-object. It
would
be nice to be able to register an enum with the meta-type system
dynamically.
Or you can set the EnumOrFlag flag in the QMetaProperty flags field to
force the
constructor to search.
Sorry, can you be more specific? I can't see how to do it given the
private nature of the flags.
Phil
Hey Phil,
How do you generate a dynamic meta object without using private APIs?
Do you use QMetaObjectBuilder (which is private), or do you generate
the tables and arrays by hand?
If you use QMetaObjectBuilder, then
QMetaPropertyBuilder::setEnumOrFlag would be the way to go.
Volker
I'm using QMetaObjectBuilder and already calling setEnumOrFlag, so that
doesn't seem to solve the problem.
An alternative that would work for me would be to bypass the new test if
the meta-type was invalid (ie. the enum wasn't registered) but I don't
know if that would nullify the purpose of the new test.
Phil
--
Fabian Kosmale
Manager R&D
The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
fabian.kosm...@qt.io
+49 1638686070
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
