Skip to content
  • 0 Votes
    4 Posts
    3k Views
    R

    @mrjj and @raven-worx , thanks for the replies! What I've gathered from this (and other posts) is: you can't use a Q_ENUM outside of QObject or a Q_GADGET macro. So in order to do what I wanted I need to change the code like this:

    #ifndef EXAMPLE_H #define EXAMPLE_H #include <QObject> struct Player { Q_GADGET public: enum class CarType { NO_CAR = 0, SLOW_CAR, FAST_CAR, HYPER_CAR }; Q_ENUM(CarType) Q_PROPERTY(Player player READ getPlayer) Q_PROPERTY(float m_speed READ getSpeed) Q_PROPERTY(CarType m_carType READ getCarType) Player getPlayer() { return *this;} float getSpeed() {return m_speed;} CarType getCarType() { return m_carType;} public: CarType m_carType; float m_speed; }; Q_DECLARE_METATYPE(Player) #endif #include <QCoreApplication> #include <iostream> #include <QMetaObject> #include "example.h" #include <QDebug> #include <QMetaProperty> int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); qRegisterMetaType<Player>(); const QMetaObject* metaObject = &Player::staticMetaObject; qInfo() << "Number of enums is: " << metaObject->enumeratorCount(); const QMetaEnum metaEnum = metaObject->enumerator(0); qInfo() << "Enum name: " << metaEnum.enumName(); int i = 0; for(i = 0; i < metaEnum.keyCount(); i++) qInfo() << "Enum key: " << metaEnum.key(i) << "; Value: " << metaEnum.value(i); return a.exec(); }

    Thanks for your time!

  • 0 Votes
    2 Posts
    355 Views
    sierdzioS

    @james_h_3010 said in Understanding QML, C++, and Enumerations:

    Does or should qmlRegisterUncreatableType and qRegisterMetaType need to go in main.cpp and be executed after QGuiApplication app? Or is considered best practice, etc.?

    It does not need to be in main.cpp. It does need to be executed after QGuiApplication.

    What you wrote is how most people do it. Is it best practice? Well, for big projects I'd say it's good to move that stuff to some other header, just to keep main.cpp cleaner. But it does not matter much, it's only styling "issue". You won't gain or loose performance here.

    console.log( "Ddddd: ", Support.Ddddd ); works, but I lose the explicit connection to the ETestB datatype. I would prefer to be able to write Support.ETestB.Ddddd or something. Is that possible now or something that might be implemented in a future version?

    I don't think it's supported and I have not heard of plans to support it. Maybe it will come, though, who knows.

    If I remove qRegisterMetaType, current behavior remains the same. I am not sure what, exactly, qRegisterMetaType is doing for me here. Can someone provide some insight...?

    Q_ENUM has already registered it with meta object system. You don't need to do it manually.

    Let's say that I add: enum class ETestC { Ggggg, Ddddd, Eeeee, Fffff }; Q_ENUM( ETestC );

    to the Support class. And qRegisterMetaType<Support::ETestC>( "Support.ETestC" ); to the main function. There is now a namespace collision between ETestC and ETestB. According to some documentation, it seems like I should add Q_CLASSINFO( "RegisterEnumClassesUnscoped", "false" ) to the Support class. However, when I do all of that, I see:

    qml: Ddddd: undefined qml: Eeeee: undefined qml: Fffff: undefined

    in the output. Clearly there is something I did not understand from the documentation.

    I look forward to hearing from anyone who cares to comment so I can understand this system better.

    I think they would clash, yes. QML engine is very stupid when it comes to understanding enums.

  • 0 Votes
    4 Posts
    4k Views
    p3c0P

    @someoneinthebox You're Welcome :)
    Btw. if you are using Qt 5.5 or greater then use Q_ENUM instead as Q_ENUMS are deprecated.