QObject Class
The QObject class is the base class of all Qt objects. More...
Note: All functions in this class are reentrant.
Properties
- objectName : QString
Public Functions
| QString | objectName() const |
| void | setObjectName(const QString &name) |
Signals
| void | objectNameChanged(const QString &objectName) |
Static Public Members
| const QMetaObject | staticMetaObject |
Related Non-Members
| typedef | QObjectList |
Macros
| QT_NO_NARROWING_CONVERSIONS_IN_CONNECT | |
| Q_CLASSINFO(Name, Value) | |
| Q_DISABLE_COPY(Class) | |
| Q_DISABLE_COPY_MOVE(Class) | |
| Q_DISABLE_MOVE(Class) | |
| Q_EMIT | |
| Q_ENUM(...) | |
| Q_ENUM_NS(...) | |
| Q_FLAG(...) | |
| Q_FLAG_NS(...) | |
| Q_GADGET | |
| Q_INTERFACES(...) | |
| Q_INVOKABLE | |
| Q_NAMESPACE | |
| Q_NAMESPACE_EXPORT(EXPORT_MACRO) | |
| Q_OBJECT | |
| Q_PROPERTY(...) | |
| Q_REVISION | |
| Q_SET_OBJECT_NAME(Object) | |
| Q_SIGNAL | |
| Q_SIGNALS | |
| Q_SLOT | |
| Q_SLOTS |
Detailed Description
QObject is the heart of the Qt Object Model. The central feature in this model is a very powerful mechanism for seamless object communication called signals and slots. You can connect a signal to a slot with connect() and destroy the connection with disconnect(). To avoid never ending notification loops you can temporarily block signals with blockSignals(). The protected functions connectNotify() and disconnectNotify() make it possible to track connections.
QObjects organize themselves in object trees. When you create a QObject with another object as parent, the object will automatically add itself to the parent's children() list. The parent takes ownership of the object; i.e., it will automatically delete its children in its destructor. You can look for an object by name and optionally type using findChild() or findChildren().
Every object has an objectName() and its class name can be found via the corresponding metaObject() (see QMetaObject::className()). You can determine whether the object's class inherits another class in the QObject inheritance hierarchy by using the inherits() function.
When an object is deleted, it emits a destroyed() signal. You can catch this signal to avoid dangling references to QObjects.
QObjects can receive events through event() and filter the events of other objects. See installEventFilter() and eventFilter() for details. A convenience handler, childEvent(), can be reimplemented to catch child events.
Last but not least, QObject provides the basic timer support in Qt; see QTimer for high-level support for timers.
Notice that the Q_OBJECT macro is mandatory for any object that implements signals, slots or properties. You also need to run the Meta Object Compiler on the source file. We strongly recommend the use of this macro in all subclasses of QObject regardless of whether or not they actually use signals, slots and properties, since failure to do so may lead certain functions to exhibit strange behavior.
All Qt widgets inherit QObject. The convenience function isWidgetType() returns whether an object is actually a widget. It is much faster than qobject_cast<QWidget *>(obj) or obj->inherits("QWidget").
Some QObject functions, e.g. children(), return a QObjectList. QObjectList is a typedef for QList<QObject *>.
Thread Affinity
A QObject instance is said to have a thread affinity, or that it lives in a certain thread. When a QObject receives a queued signal or a posted event, the slot or event handler will run in the thread that the object lives in.
Note: If a QObject has no thread affinity (that is, if thread() returns zero), or if it lives in a thread that has no running event loop, then it cannot receive queued signals or posted events.
By default, a QObject lives in the thread in which it is created. An object's thread affinity can be queried using thread() and changed using moveToThread().
All QObjects must live in the same thread as their parent. Consequently:
- setParent() will fail if the two QObjects involved live in different threads.
- When a QObject is moved to another thread, all its children will be automatically moved too.
- moveToThread() will fail if the QObject has a parent.
- If QObjects are created within QThread::run(), they cannot become children of the QThread object because the QThread does not live in the thread that calls QThread::run().
Note: A QObject's member variables do not automatically become its children. The parent-child relationship must be set by either passing a pointer to the child's constructor, or by calling setParent(). Without this step, the object's member variables will remain in the old thread when moveToThread() is called.
No Copy Constructor or Assignment Operator
QObject has neither a copy constructor nor an assignment operator. This is by design. Actually, they are declared, but in a private section with the macro Q_DISABLE_COPY(). In fact, all Qt classes derived from QObject (direct or indirect) use this macro to declare their copy constructor and assignment operator to be private. The reasoning is found in the discussion on Identity vs Value on the Qt Object Model page.
The main consequence is that you should use pointers to QObject (or to your QObject subclass) where you might otherwise be tempted to use your QObject subclass as a value. For example, without a copy constructor, you can't use a subclass of QObject as the value to be stored in one of the container classes. You must store pointers.
Auto-Connection
Qt's meta-object system provides a mechanism to automatically connect signals and slots between QObject subclasses and their children. As long as objects are defined with suitable object names, and slots follow a simple naming convention, this connection can be performed at run-time by the QMetaObject::connectSlotsByName() function.
uic generates code that invokes this function to enable auto-connection to be performed between widgets on forms created with Qt Designer. More information about using auto-connection with Qt Designer is given in the Using a Designer UI File in Your C++ Application section of the Qt Designer manual.
Dynamic Properties
From Qt 4.2, dynamic properties can be added to and removed from QObject instances at run-time. Dynamic properties do not need to be declared at compile-time, yet they provide the same advantages as static properties and are manipulated using the same API - using property() to read them and setProperty() to write them.
From Qt 4.3, dynamic properties are supported by Qt Designer, and both standard Qt widgets and user-created forms can be given dynamic properties.
Internationalization (I18n)
All QObject subclasses support Qt's translation features, making it possible to translate an application's user interface into different languages.
To make user-visible text translatable, it must be wrapped in calls to the tr() function. This is explained in detail in the Writing Source Code for Translation document.
See also QMetaObject, QPointer, QObjectCleanupHandler, Q_DISABLE_COPY(), and Object Trees & Ownership.
Property Documentation
objectName : QString
This property holds the name of this object
You can find an object by name (and type) using findChild(). You can find a set of objects with findChildren().
qDebug("MyClass::setPrecision(): (%s) invalid precision %f", qPrintable(objectName()), newPrecision);
By default, this property contains an empty string.
Access functions:
| QString | objectName() const |
| void | setObjectName(const QString &name) |
Notifier signal:
| void | objectNameChanged(const QString &objectName) | [see note below] |
Note: This is a private signal. It can be used in signal connections but cannot be emitted by the user.
See also metaObject() and QMetaObject::className().
Member Variable Documentation
const QMetaObject QObject::staticMetaObject
This variable stores the meta-object for the class.
A meta-object contains information about a class that inherits QObject, e.g. class name, superclass name, properties, signals and slots. Every class that contains the Q_OBJECT macro will also have a meta-object.
The meta-object information is required by the signal/slot connection mechanism and the property system. The inherits() function also makes use of the meta-object.
If you have a pointer to an object, you can use metaObject() to retrieve the meta-object associated with that object.
Example:
QPushButton::staticMetaObject.className(); // returns "QPushButton" QObject *obj = new QPushButton; obj->metaObject()->className(); // returns "QPushButton"
See also metaObject().
Macro Documentation
QT_NO_NARROWING_CONVERSIONS_IN_CONNECT
Defining this macro will disable narrowing and floating-point-to-integral conversions between the arguments carried by a signal and the arguments accepted by a slot, when the signal and the slot are connected using the PMF-based syntax.
This function was introduced in Qt 5.8.
See also QObject::connect.
Q_CLASSINFO(Name, Value)
This macro associates extra information to the class, which is available using QObject::metaObject(). Qt makes only limited use of this feature, in the Active Qt, Qt D-Bus and Qt QML.
The extra information takes the form of a Name string and a Value literal string.
Example:
class MyClass : public QObject { Q_OBJECT Q_CLASSINFO("Author", "Pierre Gendron") Q_CLASSINFO("URL", "http://www.my-organization.qc.ca") public: ... };
See also QMetaObject::classInfo(), QAxFactory, Using Qt D-Bus Adaptors, and Extending QML.
Q_DISABLE_COPY(Class)
Disables the use of copy constructors and assignment operators for the given Class.
Instances of subclasses of QObject should not be thought of as values that can be copied or assigned, but as unique identities. This means that when you create your own subclass of QObject (director or indirect), you should not give it a copy constructor or an assignment operator. However, it may not enough to simply omit them from your class, because, if you mistakenly write some code that requires a copy constructor or an assignment operator (it's easy to do), your compiler will thoughtfully create it for you. You must do more.
The curious user will have seen that the Qt classes derived from QObject typically include this macro in a private section:
class MyClass : public QObject { private: Q_DISABLE_COPY(MyClass) };
It declares a copy constructor and an assignment operator in the private section, so that if you use them by mistake, the compiler will report an error.
class MyClass : public QObject { private: MyClass(const MyClass &) = delete; MyClass &operator=(const MyClass &) = delete; };
But even this might not catch absolutely every case. You might be tempted to do something like this:
QWidget w = QWidget();
First of all, don't do that. Most compilers will generate code that uses the copy constructor, so the privacy violation error will be reported, but your C++ compiler is not required to generate code for this statement in a specific way. It could generate code using neither the copy constructor nor the assignment operator we made private. In that case, no error would be reported, but your application would probably crash when you called a member function of w.
See also Q_DISABLE_COPY_MOVE and Q_DISABLE_MOVE.
Q_DISABLE_COPY_MOVE(Class)
A convenience macro that disables the use of copy constructors, assignment operators, move constructors and move assignment operators for the given Class, combining Q_DISABLE_COPY and Q_DISABLE_MOVE.
This function was introduced in Qt 5.13.
See also Q_DISABLE_COPY and Q_DISABLE_MOVE.
Q_DISABLE_MOVE(Class)
Disables the use of move constructors and move assignment operators for the given Class.
This function was introduced in Qt 5.13.
See also Q_DISABLE_COPY and Q_DISABLE_COPY_MOVE.
Q_EMIT
Use this macro to replace the emit keyword for emitting signals, when you want to use Qt Signals and Slots with a 3rd party signal/slot mechanism.
The macro is normally used when no_keywords is specified with the CONFIG variable in the .pro file, but it can be used even when no_keywords is not specified.
Q_ENUM(...)
This macro registers an enum type with the meta-object system. It must be placed after the enum declaration in a class that has the Q_OBJECT or the Q_GADGET macro. For namespaces use Q_ENUM_NS() instead.
For example:
class MyClass : public QObject { Q_OBJECT public: MyClass(QObject *parent = nullptr); ~MyClass(); enum Priority { High, Low, VeryHigh, VeryLow }; Q_ENUM(Priority) void setPriority(Priority priority); Priority priority() const; };
Enumerations that are declared with Q_ENUM have their QMetaEnum registered in the enclosing QMetaObject. You can also use QMetaEnum::fromType() to get the QMetaEnum.
Registered enumerations are automatically registered also to the Qt meta type system, making them known to QMetaType without the need to use Q_DECLARE_METATYPE(). This will enable useful features; for example, if used in a QVariant, you can convert them to strings. Likewise, passing them to QDebug will print out their names.
Mind that the enum values are stored as signed int in the meta object system. Registering enumerations with values outside the range of values valid for int will lead to overflows and potentially undefined behavior when accessing them through the meta object system. QML, for example, does access registered enumerations through the meta object system.
This function was introduced in Qt 5.5.
See also Qt's Property System.
Q_ENUM_NS(...)
This macro registers an enum type with the meta-object system. It must be placed after the enum declaration in a namespace that has the Q_NAMESPACE macro. It is the same as Q_ENUM but in a namespace.
Enumerations that are declared with Q_ENUM_NS have their QMetaEnum registered in the enclosing QMetaObject. You can also use QMetaEnum::fromType() to get the QMetaEnum.
Registered enumerations are automatically registered also to the Qt meta type system, making them known to QMetaType without the need to use Q_DECLARE_METATYPE(). This will enable useful features; for example, if used in a QVariant, you can convert them to strings. Likewise, passing them to QDebug will print out their names.
Mind that the enum values are stored as signed int in the meta object system. Registering enumerations with values outside the range of values valid for int will lead to overflows and potentially undefined behavior when accessing them through the meta object system. QML, for example, does access registered enumerations through the meta object system.
This function was introduced in Qt 5.8.
See also Qt's Property System.
Q_FLAG(...)
This macro registers a single flags type with the meta-object system. It is typically used in a class definition to declare that values of a given enum can be used as flags and combined using the bitwise OR operator. For namespaces use Q_FLAG_NS() instead.
The macro must be placed after the enum declaration. The declaration of the flags type is done using the Q_DECLARE_FLAGS() macro.
For example, in QItemSelectionModel, the SelectionFlags flag is declared in the following way:
class QItemSelectionModel : public QObject { Q_OBJECT public: ... enum SelectionFlag { NoUpdate = 0x0000, Clear = 0x0001, Select = 0x0002, Deselect = 0x0004, Toggle = 0x0008, Current = 0x0010, Rows = 0x0020, Columns = 0x0040, SelectCurrent = Select | Current, ToggleCurrent = Toggle | Current, ClearAndSelect = Clear | Select }; Q_DECLARE_FLAGS(SelectionFlags, SelectionFlag) Q_FLAG(SelectionFlags) ... }
Note: The Q_FLAG macro takes care of registering individual flag values with the meta-object system, so it is unnecessary to use Q_ENUM() in addition to this macro.
This function was introduced in Qt 5.5.
See also Qt's Property System.
Q_FLAG_NS(...)
This macro registers a single flags type with the meta-object system. It is used in a namespace that has the Q_NAMESPACE macro, to declare that values of a given enum can be used as flags and combined using the bitwise OR operator. It is the same as Q_FLAG but in a namespace.
The macro must be placed after the enum declaration.
Note: The Q_FLAG_NS macro takes care of registering individual flag values with the meta-object system, so it is unnecessary to use Q_ENUM_NS() in addition to this macro.
This function was introduced in Qt 5.8.
See also Qt's Property System.
Q_GADGET
The Q_GADGET macro is a lighter version of the Q_OBJECT macro for classes that do not inherit from QObject but still want to use some of the reflection capabilities offered by QMetaObject. Just like the Q_OBJECT macro, it must appear in the private section of a class definition.
Q_GADGETs can have Q_ENUM, Q_PROPERTY and Q_INVOKABLE, but they cannot have signals or slots.
Q_GADGET makes a class member, staticMetaObject, available. staticMetaObject is of type QMetaObject and provides access to the enums declared with Q_ENUMS.
Q_INTERFACES(...)
This macro tells Qt which interfaces the class implements. This is used when implementing plugins.
Example:
class BasicToolsPlugin : public QObject, public BrushInterface, public ShapeInterface, public FilterInterface { Q_OBJECT Q_PLUGIN_METADATA(IID "org.qt-project.Qt.Examples.PlugAndPaint.BrushInterface" FILE "basictools.json") Q_INTERFACES(BrushInterface ShapeInterface FilterInterface) public: ... };
See the Plug & Paint Basic Tools example for details.
See also Q_DECLARE_INTERFACE(), Q_PLUGIN_METADATA(), and How to Create Qt Plugins.
Q_INVOKABLE
Apply this macro to declarations of member functions to allow them to be invoked via the meta-object system. The macro is written before the return type, as shown in the following example:
class Window : public QWidget { Q_OBJECT public: Window(); void normalMethod(); Q_INVOKABLE void invokableMethod(); };
The invokableMethod() function is marked up using Q_INVOKABLE, causing it to be registered with the meta-object system and enabling it to be invoked using QMetaObject::invokeMethod(). Since normalMethod() function is not registered in this way, it cannot be invoked using QMetaObject::invokeMethod().
If an invokable member function returns a pointer to a QObject or a subclass of QObject and it is invoked from QML, special ownership rules apply. See Data Type Conversion Between QML and C++ for more information.
Q_NAMESPACE
The Q_NAMESPACE macro can be used to add QMetaObject capabilities to a namespace.
Q_NAMESPACEs can have Q_CLASSINFO, Q_ENUM_NS, Q_FLAG_NS, but they cannot have Q_ENUM, Q_FLAG, Q_PROPERTY, Q_INVOKABLE, signals nor slots.
Q_NAMESPACE makes an external variable, staticMetaObject, available. staticMetaObject is of type QMetaObject and provides access to the enums declared with Q_ENUM_NS/Q_FLAG_NS.
For example:
namespace test { Q_NAMESPACE ...
This function was introduced in Qt 5.8.
See also Q_NAMESPACE_EXPORT.
Q_NAMESPACE_EXPORT(EXPORT_MACRO)
The Q_NAMESPACE_EXPORT macro can be used to add QMetaObject capabilities to a namespace.
It works exactly like the Q_NAMESPACE macro. However, the external staticMetaObject variable that gets defined in the namespace is declared with the supplied EXPORT_MACRO qualifier. This is useful if the object needs to be exported from a dynamic library.
For example:
namespace test { Q_NAMESPACE_EXPORT(EXPORT_MACRO) ...
This function was introduced in Qt 5.14.
See also Q_NAMESPACE and Creating Shared Libraries.
Q_OBJECT
The Q_OBJECT macro must appear in the private section of a class definition that declares its own signals and slots or that uses other services provided by Qt's meta-object system.
For example:
#include <QObject> class Counter : public QObject { Q_OBJECT public: Counter() { m_value = 0; } int value() const { return m_value; } public slots: void setValue(int value); signals: void valueChanged(int newValue); private: int m_value; };
Note: This macro requires the class to be a subclass of QObject. Use Q_GADGET instead of Q_OBJECT to enable the meta object system's support for enums in a class that is not a QObject subclass.
See also Meta-Object System, Signals and Slots, and Qt's Property System.
Q_PROPERTY(...)
This macro is used for declaring properties in classes that inherit QObject. Properties behave like class data members, but they have additional features accessible through the Meta-Object System.
Q_PROPERTY(type name
(READ getFunction [WRITE setFunction] |
MEMBER memberName [(READ getFunction | WRITE setFunction)])
[RESET resetFunction]
[NOTIFY notifySignal]
[REVISION int]
[DESIGNABLE bool]
[SCRIPTABLE bool]
[STORED bool]
[USER bool]
[CONSTANT]
[FINAL]
[REQUIRED])
The property name and type and the READ function are required. The type can be any type supported by QVariant, or it can be a user-defined type. The other items are optional, but a WRITE function is common. The attributes default to true except USER, which defaults to false.
For example:
Q_PROPERTY(QString title READ title WRITE setTitle USER true)
For more details about how to use this macro, and a more detailed example of its use, see the discussion on Qt's Property System.
See also Qt's Property System.
Q_REVISION
Apply this macro to declarations of member functions to tag them with a revision number in the meta-object system. The macro is written before the return type, as shown in the following example:
class Window : public QWidget { Q_OBJECT Q_PROPERTY(int normalProperty READ normalProperty) Q_PROPERTY(int newProperty READ newProperty REVISION 1) public: Window(); int normalProperty(); int newProperty(); public slots: void normalMethod(); Q_REVISION(1) void newMethod(); };
This is useful when using the meta-object system to dynamically expose objects to another API, as you can match the version expected by multiple versions of the other API. Consider the following simplified example:
Window window;
int expectedRevision = 0;
const QMetaObject *windowMetaObject = window.metaObject();
for (int i=0; i < windowMetaObject->methodCount(); i++)
if (windowMetaObject->method(i).revision() <= expectedRevision)
exposeMethod(windowMetaObject->method(i));
for (int i=0; i < windowMetaObject->propertyCount(); i++)
if (windowMetaObject->property(i).revision() <= expectedRevision)
exposeProperty(windowMetaObject->property(i));
Using the same Window class as the previous example, the newProperty and newMethod would only be exposed in this code when the expected version is 1 or greater.
Since all methods are considered to be in revision 0 if untagged, a tag of Q_REVISION(0) is invalid and ignored.
This tag is not used by the meta-object system itself. Currently this is only used by the QtQml module.
For a more generic string tag, see QMetaMethod::tag()
See also QMetaMethod::revision().
Q_SET_OBJECT_NAME(Object)
This macro assigns Object the objectName "Object".
It doesn't matter whether Object is a pointer or not, the macro figures that out by itself.
This function was introduced in Qt 5.0.
See also QObject::objectName().
Q_SIGNAL
This is an additional macro that allows you to mark a single function as a signal. It can be quite useful, especially when you use a 3rd-party source code parser which doesn't understand a signals or Q_SIGNALS groups.
Use this macro to replace the signals keyword in class declarations, when you want to use Qt Signals and Slots with a 3rd party signal/slot mechanism.
The macro is normally used when no_keywords is specified with the CONFIG variable in the .pro file, but it can be used even when no_keywords is not specified.
Q_SIGNALS
Use this macro to replace the signals keyword in class declarations, when you want to use Qt Signals and Slots with a 3rd party signal/slot mechanism.
The macro is normally used when no_keywords is specified with the CONFIG variable in the .pro file, but it can be used even when no_keywords is not specified.
Q_SLOT
This is an additional macro that allows you to mark a single function as a slot. It can be quite useful, especially when you use a 3rd-party source code parser which doesn't understand a slots or Q_SLOTS groups.
Use this macro to replace the slots keyword in class declarations, when you want to use Qt Signals and Slots with a 3rd party signal/slot mechanism.
The macro is normally used when no_keywords is specified with the CONFIG variable in the .pro file, but it can be used even when no_keywords is not specified.
Q_SLOTS
Use this macro to replace the slots keyword in class declarations, when you want to use Qt Signals and Slots with a 3rd party signal/slot mechanism.
The macro is normally used when no_keywords is specified with the CONFIG variable in the .pro file, but it can be used even when no_keywords is not specified.