accessing QObject functions from QML

mzimmers

Hi all -

I have a QObject-derived class:

class Schedule : public QObject
{
    Q_OBJECT
    QML_ELEMENT

    QUuid m_activityUuid = QUuid();
public:
    Q_PROPERTY(QUuid activityUuid READ activityUuid WRITE setActivityUuid NOTIFY activityUuidChanged FINAL)
    QUuid activityUuid() { return m_activityUuid; }
    bool setActivityUuid(QUuid activityUuid);

In my QML, I need to know whether this member is still null, or has been assigned. I'd like to do this:

TextIconButton {
    visible: scheduleCopy.activityUuid.isNull() === false

But this doesn't work, presumably because isNull() wasn't declared Q_INVOKABLE.

I've tried creating another property:

    Q_PROPERTY(bool hasActivity READ hasActivity WRITE setHasActivity NOTIFY hasActivityChanged FINAL)
    bool hasActivity() { return m_activityUuid.isNull() == false; }

But this isn't enough; I have to modify my setActivityUuid() routine to update this, which is getting messy and doesn't seem to work correctly.

Is there a better way of accomplishing this?

Thanks...

Bob64

@mzimmers I'm no expert so take anything I say with a pinch of salt, but my rule of thumb is that if the class is primarily intended to be exposed to QML then it makes sense to design its interface to be convenient to access from QML. So, in this case, I would probably have QString uuid accessors exposed to QML and just use QUuid for implementation.

If the class is also accessed directly on the C++ side, it might make sense to have a part of the interface that is not exposed to QML and is written in terms of types such as QUuid. But in general it will all depend on how the class needs to be used in practice.

Bob64

@mzimmers I haven't seen any documentation that suggests that QUuid is exposed as a type in QML. At best, I think you might see it come through to the QML side as a JS string. If that is the case, there is a standard string representation of null that you could compare against ("{00000000-0000-0000-0000-000000000000}"). Otherwise I think it is just going to be a case of modifying the Schedule interface to make it more QML-friendly.

mzimmers

@Bob64 aargh...I can see that when I designed my class, I made an assumption that turns out to be untrue.

So, should I convert my UUID members to QStrings, or handle it in my QML? Is there a "best practices" recommendation for this?

Thanks...

Bob64

@mzimmers I'm no expert so take anything I say with a pinch of salt, but my rule of thumb is that if the class is primarily intended to be exposed to QML then it makes sense to design its interface to be convenient to access from QML. So, in this case, I would probably have QString uuid accessors exposed to QML and just use QUuid for implementation.

If the class is also accessed directly on the C++ side, it might make sense to have a part of the interface that is not exposed to QML and is written in terms of types such as QUuid. But in general it will all depend on how the class needs to be used in practice.