@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.
