exposecppattributes.qdoc

Go to the documentation of this file.

// Copyright (C) 2017 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
/*!
\page qtqml-cppintegration-exposecppattributes.html
\title Exposing Attributes of C++ Types to QML
\brief Description of how to expose the attributes of a C++ type to QML.
 
QML can easily be extended with functionality defined in C++ code. Due to the
tight integration of the QML engine with the \l{The Meta-Object System}{Qt
meta-object system}, any functionality that is appropriately exposed by a
QObject-derived class or a Q_GADGET type is accessible from QML code. This
enables C++ data and functions to be accessible directly from QML, often with
little or no modification.
 
The QML engine has the ability to introspect QObject instances through the
meta-object system. This means any QML code can access the following members of
an instance of a QObject-derived class:
 
\list
\li Properties
\li Methods (providing they are public slots or flagged with Q_INVOKABLE)
\li Signals
\endlist
 
(Additionally, enums are available if they have been declared with Q_ENUM.
See \l{qtqml-cppintegration-data.html}{Data Type Conversion Between QML and C++}
for more details.)
 
In general, these are accessible from QML regardless of whether a
QObject-derived class has been \l{Registering C++ Types with the QML Type
System}{registered with the QML type system}. However, if a class is to be
used in a way that requires the engine to access additional type information
— for example, if the class itself is to be used as a method parameter or
property, or if one of its enum types is to be used in this way — then the
class may need to be registered. Registration is recommended for all types you
use in QML, as only registered types can be analyzed at compile time.
 
Registration is required for Q_GADGET types, as they don't derive from a known
common base and can't be made available automatically. Without registration,
their properties and methods are inaccessible.
 
You can make C++ types from a different module available in your own module by
adding a dependency to your \l{qt_add_qml_module} call using the \e DEPENDENCIES
option. You may, for example, want to depend on \l[Cpp]{QtQuick} so that your
QML-exposed C++ types can use \l QColor as method arguments and return values.
\l[Cpp]{QtQuick} exposes \l QColor as a \l {QML Value Types}{value type} \e color.
Such dependencies may be automatically inferred at run time, but you should not
rely on this.
 
Also note that a number of the important concepts covered in this document are
demonstrated in the \l{Writing QML Extensions with C++} tutorial.
 
For more information about C++ and the different QML integration methods,
see the
\l {Overview - QML and C++ Integration} {C++ and QML integration overview} page.
 
\section1 Data Type Handling and Ownership
 
Any data that is transferred from C++ to QML, whether as a property value, a
method parameter or return value, or a signal parameter value, must be of a
type that is supported by the QML engine.
 
By default, the engine supports a number of Qt C++ types and can automatically
convert them as appropriately when used from QML. Additionally, C++ classes
that are \l{Registering C++ Types with the QML Type System}{registered} with
the QML type system can be used as data types, as can their enums if
appropriately registered. See \l{qtqml-cppintegration-data.html}{Data Type
Conversion Between QML and C++} for further information.
 
Additionally, data ownership rules are taken into consideration when data is
transferred from C++ to QML. See \l {Data Ownership} for more details.
 
 
\section1 Exposing Properties
 
A \e property can be specified for any QObject-derived class using the
Q_PROPERTY() macro. A property is a class data member with an associated read
function and optional write function.
 
All properties of a QObject-derived or Q_GADGET class are accessible from QML.
 
For example, below is a \c Message class with an \c author property. As
specified by the Q_PROPERTY macro call, this property is readable through
the \c author() method, and writable through the \c setAuthor() method:
 
\note Do not use \e typedef or \e using for Q_PROPERTY types as these
will confuse moc. This may make certain type comparisons fail.
 
Instead of:
 
\badcode
using FooEnum = Foo::Enum;
 
class Bar : public QObject
{
    Q_OBJECT
    Q_PROPERTY(FooEnum enum READ enum WRITE setEnum NOTIFY enumChanged)
};
\endcode
 
Refer to the type directly:
 
\code
class Bar : public QObject
{
    Q_OBJECT
    Q_PROPERTY(Foo::Enum enum READ enum WRITE setEnum NOTIFY enumChanged)
};
\endcode
 
In order to make \c Message available you need to use \l{QML_ELEMENT} in C++
and \l{qt_add_qml_module} in CMake.
 
\code
class Message : public QObject
{
    Q_OBJECT
    QML_ELEMENT
    Q_PROPERTY(QString author READ author WRITE setAuthor NOTIFY authorChanged)
public:
    void setAuthor(const QString &a)
    {
        if (a != m_author) {
            m_author = a;
            emit authorChanged();
        }
    }
 
    QString author() const
    {
        return m_author;
    }
 
signals:
    void authorChanged();
 
private:
    QString m_author;
};
\endcode
 
An instance of \c Message can be passed as required property to a file called
\c MyItem.qml to make it available:
 
\code
 int main(int argc, char *argv[]) {
     QGuiApplication app(argc, argv);
 
     QQuickView view;
     Message msg;
     view.setInitialProperties({{"msg", &msg}});
     view.setSource(QUrl::fromLocalFile("MyItem.qml"));
     view.show();
 
     return app.exec();
 }
\endcode
 
Then, the \c author property could be read from \c MyItem.qml:
 
\qml
// MyItem.qml
import QtQuick
 
Text {
    required property Message msg
 
    width: 100; height: 100
    text: msg.author    // invokes Message::author() to get this value
 
    Component.onCompleted: {
        msg.author = "Jonah"  // invokes Message::setAuthor()
    }
}
\endqml
 
For maximum interoperability with QML, \b {any property that is writable should
have an associated NOTIFY signal} that is emitted whenever the property value
has changed. This allows the property to be used with \l{Property
Binding}{property binding}, which is an essential feature of QML that enforces
relationships between properties by automatically updating a property whenever
any of its dependencies change in value.
 
In the above example, the associated NOTIFY signal for the \c author property is
\c authorChanged, as specified in the Q_PROPERTY() macro call. This means that
whenever the signal is emitted — as it is when the author changes
in Message::setAuthor() — this notifies the QML engine that any
bindings involving the \c author property must be updated, and in turn, the
engine will update the \c text property by calling \c Message::author() again.
 
If the \c author property was writable but did not have an associated NOTIFY
signal, the \c text value would be initialized with the initial value returned
by \c Message::author() but would not be updated with any later changes to this
property. In addition, any attempts to bind to the property from QML will
produce a runtime warning from the engine.
 
\note It is recommended that the NOTIFY signal be named \e <property>Changed
where \c <property> is the name of the property. The associated property
change signal handler generated by the QML engine will always take the form
\c on<Property>Changed, regardless of the name of the related C++ signal, so
it is recommended that the signal name follows this convention to avoid any
confusion.
 
 
\section3 Notes on Use of Notify Signals
 
To prevent loops or excessive evaluation, developers should ensure that the
property change signal is only emitted when the property value has actually
changed. Also, if a property or group of properties is infrequently used, it
is permitted to use the same NOTIFY signal for several properties. This should
be done with care to ensure that performance doesn't suffer.
 
The presence of a NOTIFY signal does incur a small overhead. There are cases
where a property's value is set at object construction time, and does not
subsequently change. The most common case of this is a read-only property that
holds a sub-object, typically accessed through
\l{#Grouped Properties}{grouped property syntax}, where the sub-object is
allocated once, and only freed when the owner is deleted. In these cases,
the CONSTANT attribute may be added to the property declaration instead of a
NOTIFY signal.
 
The CONSTANT attribute should only be used for properties whose value is set,
and finalized, only in the class constructor.  All other properties that want
to be used in bindings should have a NOTIFY signal instead.
 
 
\section2 Properties with Object Types
 
Object-type properties are accessible from QML providing that the object type
has been appropriately \l{Registering C++ Types with the QML Type
System}{registered} with the QML type system.
 
For example, the \c Message type might have a \c body property of type
\c MessageBody*:
 
\code
class Message : public QObject
{
    Q_OBJECT
    Q_PROPERTY(MessageBody* body READ body WRITE setBody NOTIFY bodyChanged)
public:
    MessageBody* body() const;
    void setBody(MessageBody* body);
};
 
class MessageBody : public QObject
{
    Q_OBJECT
    Q_PROPERTY(QString text READ text WRITE text NOTIFY textChanged)
// ...
}
\endcode
 
Suppose the \c Message type was \l{Registering C++ Types with the QML Type
System}{registered} with the QML type system, allowing it to be used as an
object type from QML code:
 
\qml
Message {
    // ...
}
\endqml
 
If the \c MessageBody type was also registered with the type system, it would be
possible to assign \c MessageBody to the \c body property of a \c Message, all
from within QML code:
 
\qml
Message {
    body: MessageBody {
        text: "Hello, world!"
    }
}
\endqml
 
 
\section2 Properties with Object-List Types
 
Properties containing lists of QObject-derived types can also be exposed to
QML. For this purpose, however, one should use QQmlListProperty rather than
QList<T> as the property type. This is because QList is not a QObject-derived
type, and so cannot provide the necessary QML property characteristics
through the Qt meta object system, such as signal notifications when a list
is modified.
 
For example, the \c MessageBoard class below has a \c messages property of
type QQmlListProperty that stores a list of \c Message instances:
 
\code
class MessageBoard : public QObject
{
    Q_OBJECT
    Q_PROPERTY(QQmlListProperty<Message> messages READ messages)
public:
    QQmlListProperty<Message> messages();
 
private:
    static void append_message(QQmlListProperty<Message> *list, Message *msg);
 
    QList<Message *> m_messages;
};
\endcode
 
The MessageBoard::messages() function simply creates and returns a
QQmlListProperty from its QList<T> \c m_messages member, passing the
appropriate list modification functions as required by the QQmlListProperty
constructor:
 
\code
QQmlListProperty<Message> MessageBoard::messages()
{
    return QQmlListProperty<Message>(this, 0, &MessageBoard::append_message);
}
 
void MessageBoard::append_message(QQmlListProperty<Message> *list, Message *msg)
{
    MessageBoard *msgBoard = qobject_cast<MessageBoard *>(list->object);
    if (msg)
        msgBoard->m_messages.append(msg);
}
\endcode
 
Note that the template class type for the QQmlListProperty — in this case,
\c Message — must be \l{Registering C++ Types with the QML Type System}
{registered} with the QML type system.
 
 
\section2 Grouped Properties
\keyword Integrating QML and C++ - Grouped Properties
 
Any property whose type has sub-properties of its own can be manipulated using
the \l{QML Object Attributes#Grouped Properties}{grouped property syntax}, no
matter whether that type is a value type such as \c font or an object type.
Grouped properties are useful to expose a group of related properties that
describe a set of attributes for a type.
 
For example, suppose the \c Message::author property was of type
\c MessageAuthor rather than a simple string, with sub-properties
of \c name and \c email:
 
\code
class MessageAuthor : public QObject
{
    Q_PROPERTY(QString name READ name WRITE setName)
    Q_PROPERTY(QString email READ email WRITE setEmail)
public:
    ...
};
 
class Message : public QObject
{
    Q_OBJECT
    Q_PROPERTY(MessageAuthor* author READ author)
public:
    Message(QObject *parent)
        : QObject(parent), m_author(new MessageAuthor(this))
    {
    }
    MessageAuthor *author() const {
        return m_author;
    }
private:
    MessageAuthor *m_author;
};
\endcode
 
The \c author property could be written to using the
\l{QML Object Attributes#Grouped Properties}{grouped property syntax} in QML,
like this:
 
\qml
Message {
    author.name: "Alexandra"
    author.email: "alexandra@mail.com"
}
\endqml
 
Since \c author is an \l{Properties with Object Types}{object-type property},
the grouped assignments do not create the \c MessageAuthor object. They are
written to whatever object \c Message::author() returns. This has a few
consequences:
 
\list
\li The sub-property names are resolved against the \e declared type of the
    property, here \c MessageAuthor, not against the type of the object that
    happens to be stored in it at run time. Different instantiations of
    \c Message could produce \c author objects of different types. The only
    thing we can rely on when creating the QML component is the declared type.
\li The object has to exist when the grouped assignments are applied.
    Otherwise the engine throws an error along the lines of
    \c {Cannot set properties on author as it is null}. Creating the object in
    the owner's constructor, as above, is the simplest way to guarantee this,
    but a getter that creates the object on first access works just as well.
\li The lifetime of the object is whatever the C++ implementation makes it.
    Grouped property syntax neither creates nor destroys objects.
\endlist
 
Declaring \c author read-only, as in the example above, additionally prevents
QML code from replacing the \c MessageAuthor object. If \c author had a
\c WRITE accessor, you could equally well assign a new object to it:
 
\qml
Message {
    author: MessageAuthor {
        name: "Alexandra"
        email: "alexandra@mail.com"
    }
}
\endqml
 
You cannot combine the two forms for the same property in the same
object definition. Assigning an object to \c author and also writing
\c author.name in the same \c Message produces an error. You can subvert that
by having the grouped property in a different scope. However, doing so produces
confusing results because now you have two \c MessageAuthor objects, the one
created by the constructor and the one assigned explicitly. Only binding
evaluation order determines which one the grouped property applies to.
 
This means that the good practice is:
 
\list
\li Keep objects used as grouped properties read-only.
\li Avoid grouped property syntax if you also manipulate the base property of
    the group itself.
\endlist
 
For a \l {QML Value Types}{value type} property such as \c font, grouped
assignments require the property to be writable, since the engine reads the
value, modifies it, and writes it back. The potential confusion is still a
problem, though. If you re-assign the whole \c font in place and then manipulate
the \c font.bold property in a different place, binding evaluation order
determines which one is done first, and what value of \c bold will result from
it.
 
 
\section1 Exposing Methods (Including Qt Slots)
 
Any method of a QObject-derived type is accessible from QML code if it is:
 
\list
\li A public method flagged with the Q_INVOKABLE() macro
\li A method that is a public Qt \l{Signals & Slots}{slot}
\endlist
 
For example, the \c MessageBoard class below has a \c postMessage() method that
has been flagged with the Q_INVOKABLE macro, as well as a \c refresh() method
that is a public slot:
 
\code
 class MessageBoard : public QObject
 {
     Q_OBJECT
     QML_ELEMENT
 
 public:
     Q_INVOKABLE bool postMessage(const QString &msg) {
         qDebug() << "Called the C++ method with" << msg;
         return true;
     }
 
 public slots:
     void refresh() {
         qDebug() << "Called the C++ slot";
     }
 };
\endcode
 
If an instance of \c MessageBoard was set as the required property for a file \c
MyItem.qml, then \c MyItem.qml could invoke the two methods as shown in the
examples below:
 
\table
\row
\li C++
\li
\code
 int main(int argc, char *argv[]) {
     QGuiApplication app(argc, argv);
 
     MessageBoard msgBoard;
     QQuickView view;
     view.setInitialProperties({{"msgBoard", &msgBoard}});
     view.setSource(QUrl::fromLocalFile("MyItem.qml"));
     view.show();
 
     return app.exec();
 }
\endcode
\row
\li QML
\li
\qml
// MyItem.qml
import QtQuick 2.0
 
Item {
    required property MessageBoard msgBoard
 
    width: 100; height: 100
 
    MouseArea {
        anchors.fill: parent
        onClicked: {
            var result = msgBoard.postMessage("Hello from QML")
            console.log("Result of postMessage():", result)
            msgBoard.refresh();
        }
    }
}
\endqml
\endtable
 
If a C++ method has a parameter with a \c QObject* type, the parameter value
can be passed from QML using an object \c id or a JavaScript \l var value
that references the object.
 
QML supports the calling of overloaded C++ functions. If there are multiple C++
functions with the same name but different arguments, the correct function will
be called according to the number and the types of arguments that are provided.
 
Values returned from C++ methods are converted to JavaScript values when
accessed from JavaScript expressions in QML.
 
\section2 C++ methods and the 'this' object
 
You may want to retrieve a C++ method from one object and call it on a different
object. Consider the following example, within a QML module called \c{Example}:
 
\table
\row
\li C++
\li
\code
class Invokable : public QObject
{
    Q_OBJECT
    QML_ELEMENT
public:
    Invokable(QObject *parent = nullptr) : QObject(parent) {}
 
    Q_INVOKABLE void invoke() { qDebug() << "invoked on " << objectName(); }
};
\endcode
\row
\li QML
\li
\qml
import QtQml
import Example
 
Invokable {
    objectName: "parent"
    property Invokable child: Invokable {}
    Component.onCompleted: child.invoke.call(this)
}
\endqml
\endtable
 
If you load the QML code from a suitable main.cpp, it should print
"invoked on parent". However, due to a long standing bug, it doesn't.
Historically, the 'this' object of C++-based methods is inseparably bound to
the method. Changing this behavior for existing code would cause subtle errors
since the 'this' object is implicit in many places. Since Qt 6.5 you can
explicitly opt into the correct behavior and allow C++ methods to accept a
'this' object. To do so, add the following pragma to your QML documents:
 
\qml
pragma NativeMethodBehavior: AcceptThisObject
\endqml
 
With this line added, the example above will work as expected.
 
\section2 Overriding toString()
 
If you provide a Q_INVOKABLE method called \e{toString} (with no arguments), that
method will be used to convert the object to a string in place of JavaScript's
native \e{toString} implementation.
 
\section1 Exposing Signals
 
Any public \l{Signals & Slots}{signal} of a QObject-derived type is accessible
from QML code.
 
The QML engine automatically creates a \l{Signal and Handler Event
System}{signal handler} for any signal of a QObject-derived type that is used
from QML. Signal handlers are always named \e on<Signal> where \c <Signal> is
the name of the signal, with the first letter capitalized. All parameters passed
by the signal are available in the signal handler through the parameter names.
 
For example, suppose the \c MessageBoard class has a \c newMessagePosted()
signal with a single parameter, \c subject:
 
\code
 class MessageBoard : public QObject
 {
     Q_OBJECT
 public:
    // ...
 signals:
    void newMessagePosted(const QString &subject);
 };
\endcode
 
If the \c MessageBoard type was \l{Registering C++ Types with the QML Type
System}{registered} with the QML type system, then a \c MessageBoard object
declared in QML could receive the \c newMessagePosted() signal using a signal
handler named \c onNewMessagePosted, and examine the \c subject parameter
value:
 
\qml
MessageBoard {
    onNewMessagePosted: (subject)=> console.log("New message received:", subject)
}
\endqml
 
As with property values and method parameters, a signal parameter must have a
type that is supported by the QML engine; see
\l {Data Type Conversion Between QML and C++}. (Using an
unregistered type will not generate an error, but the parameter value will
not be accessible from the handler.)
 
Classes may have multiple signals with the same name, but only the final
signal is accessible as a QML signal. Note that signals with the same name
but different parameters cannot be distinguished from one another.
 
\sa {qqmlintegration.h}{QML Type Registration Macros}, {Defining QML Types from C++}
*/