@Kamichanw Unfortunately, you can't. "ReferenceError: main is not defined"

@kshegunov I have ~80 classes, each with 5-10 different properties (enums, POD, custom types, containers). The problem are all implicit (in a loop) conversions of these properties.

@fcarney Thanks a million. That was the problem.
And thanks for the advice.

@HenkKalkwater said in QML: QMetaProperty::read unable to handle for some enums defined in C++, but not all:

Anyways, a huge thank you for your help. I´ve been stuck on this for about 2 days.

Your welcome, I am glad I could help you :)

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

@mrjj

This is what I'm looking for, thank you.

@SpaceToon
If you are determined to keep the signal class and the slot class separate without sharing a common enum, but you are prepared to do things via a common "controller" class, you can proceed as follows:

Export the two enums from their .h files. Import these two files into the "controller" class. Have the controller class place the connect() from the signal class to the slot class. The call to the connect() attaches the signal with its enum to a lambda (or similar) in the controller which maps/translates the signal's enum value to the corresponding slot's enum value.

I registered it as RegiterType cause it is model derived from QAbstractListModel, enum is inside it. I would like to keep enum inside it rather than new header

Update:
I can do if(rolenamefortype === 0) etc, cause it's int based like C style enum. However I would like to do if(rolenamefortype === model.TYPEA) cause of clarity

Thanks a zillion. For the record:

qtexttospeech.h already has on line 118 Q_DECLARE_METATYPE(QTextToSpeech::State)

Hence, what's missing is the qRegisterMetaType part. Which I am adding in main.cpp before the QTextToSpeech module is loaded.

qRegisterMetaType<QTextToSpeech::State>("State"); QTextToSpeech* speech = new QTextToSpeech;

Then, in main.qml, I am catching the state changed signals and the state like this:

Connections { target: speech onStateChanged: { console.log("speech.state "+ speech.state); if (speech.state == 1){ console.log("--- we are speaking! ---"); } else if (speech.state == 0){ console.log("--- speaking stopped! ---"); } } }

@ankit-thakar

I don't know why you don't like it, but the usual way is to add a dummy at the end.

@Devopia53

My issue with that solution is that you're getting the information at runtime, instead of at compile time. There is increased chance of errors and there isn't really a need to inquire the meta object system in this case.

Let me tone down this discussion by saying that the original reason for my question has disappeared. I misunderstood how QPrinter worked. I thought I would need the string versions of the QPrintDialog enums to pass on to lp. Turns out QPrinter does what I need to do automatically and I don't need to call lp. Thanks for the lively discussion though.

You could only do it by C++

See this article:

The Property System | Qt Core 5.5

Hi and welcome to devnet,

Good question, however the documentation about the qHash function states that the function must be in the namespace

Received answer on Stack Overflow.
Note: The names of enum values must begin with a capital letter in order to be accessible from QML.