QObject Class
The QObject class is the base class of all Qt objects. More...
Header: | #include <QObject> |
qmake: | QT += core |
Inherited By: | QAbstractAnimation, QAbstractEventDispatcher, QAbstractItemModel, QAbstractState, QAbstractTransition, QCoreApplication, QEventLoop, QFileSelector, QFileSystemWatcher, QIODevice, QItemSelectionModel, QLibrary, QMimeData, QObjectCleanupHandler, QPluginLoader, QSettings, QSharedMemory, QSignalMapper, QSocketNotifier, QThread, QThreadPool, QTimeLine, QTimer, QTranslator, and QWinEventNotifier |
Note: All functions in this class are reentrant.
Note: These functions are also thread-safe:
- connect(const QObject *sender, const char *signal, const QObject *receiver, const char *method, Qt::ConnectionType type)
- disconnect(const QObject *sender, const char *signal, const QObject *receiver, const char *method)
Properties
- objectName : QString
Public Functions
QObject(QObject *parent = nullptr) | |
virtual | ~QObject() |
bool | blockSignals(bool block) |
void | dumpObjectInfo() const |
void | dumpObjectTree() const |
QList<QByteArray> | dynamicPropertyNames() const |
virtual bool | event(QEvent *e) |
virtual bool | eventFilter(QObject *watched, QEvent *event) |
void | killTimer(int id) |
void | moveToThread(QThread *targetThread) |
QString | objectName() const |
QVariant | property(const char *name) const |
void | removeEventFilter(QObject *obj) |
void | setObjectName(const QString &name) |
void | setParent(QObject *parent) |
bool | setProperty(const char *name, const QVariant &value) |
int | startTimer(int interval, Qt::TimerType timerType = Qt::CoarseTimer) |
QThread * | thread() const |
Public Slots
void | deleteLater() |
Signals
void | objectNameChanged(const QString &objectName) |
Static Public Members
QMetaObject::Connection | connect(const QObject *sender, const char *signal, const QObject *receiver, const char *method, Qt::ConnectionType type = Qt::AutoConnection) |
QMetaObject::Connection | connect(const QObject *sender, const QMetaMethod &signal, const QObject *receiver, const QMetaMethod &method, Qt::ConnectionType type = Qt::AutoConnection) |
bool | disconnect(const QObject *sender, const char *signal, const QObject *receiver, const char *method) |
bool | disconnect(const QObject *sender, const QMetaMethod &signal, const QObject *receiver, const QMetaMethod &method) |
bool | disconnect(const QMetaObject::Connection &connection) |
const QMetaObject | staticMetaObject |
Protected Functions
virtual void | childEvent(QChildEvent *event) |
virtual void | connectNotify(const QMetaMethod &signal) |
virtual void | customEvent(QEvent *event) |
virtual void | disconnectNotify(const QMetaMethod &signal) |
bool | isSignalConnected(const QMetaMethod &signal) const |
int | receivers(const char *signal) const |
QObject * | sender() const |
int | senderSignalIndex() const |
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_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 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 Function Documentation
QObject::QObject(QObject *parent = nullptr)
Constructs an object with parent object parent.
The parent of an object may be viewed as the object's owner. For instance, a dialog box is the parent of the OK and Cancel buttons it contains.
The destructor of a parent object destroys all child objects.
Setting parent to 0 constructs an object with no parent. If the object is a widget, it will become a top-level window.
Note: This function can be invoked via the meta-object system and from QML. See Q_INVOKABLE.
See also parent(), findChild(), and findChildren().
[slot]
void QObject::deleteLater()
Schedules this object for deletion.
The object will be deleted when control returns to the event loop. If the event loop is not running when this function is called (e.g. deleteLater() is called on an object before QCoreApplication::exec()), the object will be deleted once the event loop is started. If deleteLater() is called after the main event loop has stopped, the object will not be deleted. Since Qt 4.8, if deleteLater() is called on an object that lives in a thread with no running event loop, the object will be destroyed when the thread finishes.
Note that entering and leaving a new event loop (e.g., by opening a modal dialog) will not perform the deferred deletion; for the object to be deleted, the control must return to the event loop from which deleteLater() was called. This does not apply to objects deleted while a previous, nested event loop was still running: the Qt event loop will delete those objects as soon as the new nested event loop starts.
Note: It is safe to call this function more than once; when the first deferred deletion event is delivered, any pending events for the object are removed from the event queue.
See also destroyed() and QPointer.
[virtual]
QObject::~QObject()
Destroys the object, deleting all its child objects.
All signals to and from the object are automatically disconnected, and any pending posted events for the object are removed from the event queue. However, it is often safer to use deleteLater() rather than deleting a QObject subclass directly.
Warning: All child objects are deleted. If any of these objects are on the stack or global, sooner or later your program will crash. We do not recommend holding pointers to child objects from outside the parent. If you still do, the destroyed() signal gives you an opportunity to detect when an object is destroyed.
Warning: Deleting a QObject while pending events are waiting to be delivered can cause a crash. You must not delete the QObject directly if it exists in a different thread than the one currently executing. Use deleteLater() instead, which will cause the event loop to delete the object after all pending events have been delivered to it.
See also deleteLater().
bool QObject::blockSignals(bool block)
If block is true, signals emitted by this object are blocked (i.e., emitting a signal will not invoke anything connected to it). If block is false, no such blocking will occur.
The return value is the previous value of signalsBlocked().
Note that the destroyed() signal will be emitted even if the signals for this object have been blocked.
Signals emitted while being blocked are not buffered.
See also signalsBlocked() and QSignalBlocker.
[virtual protected]
void QObject::childEvent(QChildEvent *event)
This event handler can be reimplemented in a subclass to receive child events. The event is passed in the event parameter.
QEvent::ChildAdded and QEvent::ChildRemoved events are sent to objects when children are added or removed. In both cases you can only rely on the child being a QObject, or if isWidgetType() returns true
, a QWidget. (This is because, in the ChildAdded case, the child is not yet fully constructed, and in the ChildRemoved case it might have been destructed already).
QEvent::ChildPolished events are sent to widgets when children are polished, or when polished children are added. If you receive a child polished event, the child's construction is usually completed. However, this is not guaranteed, and multiple polish events may be delivered during the execution of a widget's constructor.
For every child widget, you receive one ChildAdded event, zero or more ChildPolished events, and one ChildRemoved event.
The ChildPolished event is omitted if a child is removed immediately after it is added. If a child is polished several times during construction and destruction, you may receive several child polished events for the same child, each time with a different virtual table.
See also event().
[static]
QMetaObject::Connection QObject::connect(const QObject *sender, const char *signal, const QObject *receiver, const char *method, Qt::ConnectionType type = Qt::AutoConnection)
Creates a connection of the given type from the signal in the sender object to the method in the receiver object. Returns a handle to the connection that can be used to disconnect it later.
You must use the SIGNAL()
and SLOT()
macros when specifying the signal and the method, for example:
QLabel *label = new QLabel; QScrollBar *scrollBar = new QScrollBar; QObject::connect(scrollBar, SIGNAL(valueChanged(int)), label, SLOT(setNum(int)));
This example ensures that the label always displays the current scroll bar value. Note that the signal and slots parameters must not contain any variable names, only the type. E.g. the following would not work and return false:
// WRONG QObject::connect(scrollBar, SIGNAL(valueChanged(int value)), label, SLOT(setNum(int value)));
A signal can also be connected to another signal:
class MyWidget : public QWidget { Q_OBJECT public: MyWidget(); signals: void buttonClicked(); private: QPushButton *myButton; }; MyWidget::MyWidget() { myButton = new QPushButton(this); connect(myButton, SIGNAL(clicked()), this, SIGNAL(buttonClicked())); }
In this example, the MyWidget
constructor relays a signal from a private member variable, and makes it available under a name that relates to MyWidget
.
A signal can be connected to many slots and signals. Many signals can be connected to one slot.
If a signal is connected to several slots, the slots are activated in the same order in which the connections were made, when the signal is emitted.
The function returns a QMetaObject::Connection that represents a handle to a connection if it successfully connects the signal to the slot. The connection handle will be invalid if it cannot create the connection, for example, if QObject is unable to verify the existence of either signal or method, or if their signatures aren't compatible. You can check if the handle is valid by casting it to a bool.
By default, a signal is emitted for every connection you make; two signals are emitted for duplicate connections. You can break all of these connections with a single disconnect() call. If you pass the Qt::UniqueConnection type, the connection will only be made if it is not a duplicate. If there is already a duplicate (exact same signal to the exact same slot on the same objects), the connection will fail and connect will return an invalid QMetaObject::Connection.
Note: Qt::UniqueConnections do not work for lambdas, non-member functions and functors; they only apply to connecting to member functions.
The optional type parameter describes the type of connection to establish. In particular, it determines whether a particular signal is delivered to a slot immediately or queued for delivery at a later time. If the signal is queued, the parameters must be of types that are known to Qt's meta-object system, because Qt needs to copy the arguments to store them in an event behind the scenes. If you try to use a queued connection and get the error message
QObject::connect: Cannot queue arguments of type 'MyType' (Make sure 'MyType' is registered using qRegisterMetaType().)
call qRegisterMetaType() to register the data type before you establish the connection.
Note: This function is thread-safe.
See also disconnect(), sender(), qRegisterMetaType(), Q_DECLARE_METATYPE(), and Differences between String-Based and Functor-Based Connections.
[static]
QMetaObject::Connection QObject::connect(const QObject *sender, const QMetaMethod &signal, const QObject *receiver, const QMetaMethod &method, Qt::ConnectionType type = Qt::AutoConnection)
Creates a connection of the given type from the signal in the sender object to the method in the receiver object. Returns a handle to the connection that can be used to disconnect it later.
The Connection handle will be invalid if it cannot create the connection, for example, the parameters were invalid. You can check if the QMetaObject::Connection is valid by casting it to a bool.
This function works in the same way as connect(const QObject *sender, const char *signal, const QObject *receiver, const char *method, Qt::ConnectionType type)
but it uses QMetaMethod to specify signal and method.
This function was introduced in Qt 4.8.
See also connect(const QObject *sender, const char *signal, const QObject *receiver, const char *method, Qt::ConnectionType type).
[virtual protected]
void QObject::connectNotify(const QMetaMethod &signal)
This virtual function is called when something has been connected to signal in this object.
If you want to compare signal with a specific signal, you can use QMetaMethod::fromSignal() as follows:
if (signal == QMetaMethod::fromSignal(&MyObject::valueChanged)) { // signal is valueChanged }
Warning: This function violates the object-oriented principle of modularity. However, it might be useful when you need to perform expensive initialization only if something is connected to a signal.
Warning: This function is called from the thread which performs the connection, which may be a different thread from the thread in which this object lives.
This function was introduced in Qt 5.0.
See also connect() and disconnectNotify().
[virtual protected]
void QObject::customEvent(QEvent *event)
This event handler can be reimplemented in a subclass to receive custom events. Custom events are user-defined events with a type value at least as large as the QEvent::User item of the QEvent::Type enum, and is typically a QEvent subclass. The event is passed in the event parameter.
[static]
bool QObject::disconnect(const QObject *sender, const char *signal, const QObject *receiver, const char *method)
Disconnects signal in object sender from method in object receiver. Returns true
if the connection is successfully broken; otherwise returns false
.
A signal-slot connection is removed when either of the objects involved are destroyed.
disconnect() is typically used in three ways, as the following examples demonstrate.
- Disconnect everything connected to an object's signals:
disconnect(myObject, 0, 0, 0);
equivalent to the non-static overloaded function
myObject->disconnect();
- Disconnect everything connected to a specific signal:
disconnect(myObject, SIGNAL(mySignal()), 0, 0);
equivalent to the non-static overloaded function
myObject->disconnect(SIGNAL(mySignal()));
- Disconnect a specific receiver:
disconnect(myObject, 0, myReceiver, 0);
equivalent to the non-static overloaded function
myObject->disconnect(myReceiver);
0 may be used as a wildcard, meaning "any signal", "any receiving object", or "any slot in the receiving object", respectively.
The sender may never be 0. (You cannot disconnect signals from more than one object in a single call.)
If signal is 0, it disconnects receiver and method from any signal. If not, only the specified signal is disconnected.
If receiver is 0, it disconnects anything connected to signal. If not, slots in objects other than receiver are not disconnected.
If method is 0, it disconnects anything that is connected to receiver. If not, only slots named method will be disconnected, and all other slots are left alone. The method must be 0 if receiver is left out, so you cannot disconnect a specifically-named slot on all objects.
Note: This function is thread-safe.
See also connect().
[static]
bool QObject::disconnect(const QObject *sender, const QMetaMethod &signal, const QObject *receiver, const QMetaMethod &method)
Disconnects signal in object sender from method in object receiver. Returns true
if the connection is successfully broken; otherwise returns false
.
This function provides the same possibilities like disconnect(const QObject *sender, const char *signal, const QObject *receiver, const char *method)
but uses QMetaMethod to represent the signal and the method to be disconnected.
Additionally this function returnsfalse and no signals and slots disconnected if:
- signal is not a member of sender class or one of its parent classes.
- method is not a member of receiver class or one of its parent classes.
- signal instance represents not a signal.
QMetaMethod() may be used as wildcard in the meaning "any signal" or "any slot in receiving object". In the same way 0 can be used for receiver in the meaning "any receiving object". In this case method should also be QMetaMethod(). sender parameter should be never 0.
This function was introduced in Qt 4.8.
See also disconnect(const QObject *sender, const char *signal, const QObject *receiver, const char *method).
[static]
bool QObject::disconnect(const QMetaObject::Connection &connection)
Disconnect a connection.
If the connection is invalid or has already been disconnected, do nothing and return false.
See also connect().
[virtual protected]
void QObject::disconnectNotify(const QMetaMethod &signal)
This virtual function is called when something has been disconnected from signal in this object.
See connectNotify() for an example of how to compare signal with a specific signal.
If all signals were disconnected from this object (e.g., the signal argument to disconnect() was 0), disconnectNotify() is only called once, and the signal will be an invalid QMetaMethod (QMetaMethod::isValid() returns false
).
Warning: This function violates the object-oriented principle of modularity. However, it might be useful for optimizing access to expensive resources.
Warning: This function is called from the thread which performs the disconnection, which may be a different thread from the thread in which this object lives. This function may also be called with a QObject internal mutex locked. It is therefore not allowed to re-enter any of any QObject functions from your reimplementation and if you lock a mutex in your reimplementation, make sure that you don't call QObject functions with that mutex held in other places or it will result in a deadlock.
This function was introduced in Qt 5.0.
See also disconnect() and connectNotify().
void QObject::dumpObjectInfo() const
Dumps information about signal connections, etc. for this object to the debug output.
Note: before Qt 5.9, this function was not const.
See also dumpObjectTree().
void QObject::dumpObjectTree() const
Dumps a tree of children to the debug output.
Note: before Qt 5.9, this function was not const.
See also dumpObjectInfo().
QList<QByteArray> QObject::dynamicPropertyNames() const
Returns the names of all properties that were dynamically added to the object using setProperty().
This function was introduced in Qt 4.2.
[virtual]
bool QObject::event(QEvent *e)
This virtual function receives events to an object and should return true if the event e was recognized and processed.
The event() function can be reimplemented to customize the behavior of an object.
Make sure you call the parent event class implementation for all the events you did not handle.
Example:
class MyClass : public QWidget { Q_OBJECT public: MyClass(QWidget *parent = 0); ~MyClass(); bool event(QEvent* ev) override { if (ev->type() == QEvent::PolishRequest) { // overwrite handling of PolishRequest if any doThings(); return true; } else if (ev->type() == QEvent::Show) { // complement handling of Show if any doThings2(); QWidget::event(ev); return true; } // Make sure the rest of events are handled return QWidget::event(ev); } };
See also installEventFilter(), timerEvent(), QCoreApplication::sendEvent(), and QCoreApplication::postEvent().
[virtual]
bool QObject::eventFilter(QObject *watched, QEvent *event)
Filters events if this object has been installed as an event filter for the watched object.
In your reimplementation of this function, if you want to filter the event out, i.e. stop it being handled further, return true; otherwise return false.
Example:
class MainWindow : public QMainWindow { public: MainWindow(); protected: bool eventFilter(QObject *obj, QEvent *ev) override; private: QTextEdit *textEdit; }; MainWindow::MainWindow() { textEdit = new QTextEdit; setCentralWidget(textEdit); textEdit->installEventFilter(this); } bool MainWindow::eventFilter(QObject *obj, QEvent *event) { if (obj == textEdit) { if (event->type() == QEvent::KeyPress) { QKeyEvent *keyEvent = static_cast<QKeyEvent*>(event); qDebug() << "Ate key press" << keyEvent->key(); return true; } else { return false; } } else { // pass the event on to the parent class return QMainWindow::eventFilter(obj, event); } }
Notice in the example above that unhandled events are passed to the base class's eventFilter() function, since the base class might have reimplemented eventFilter() for its own internal purposes.
Some events, such as QEvent::ShortcutOverride must be explicitly accepted (by calling accept() on them) in order to prevent propagation.
Warning: If you delete the receiver object in this function, be sure to return true. Otherwise, Qt will forward the event to the deleted object and the program might crash.
See also installEventFilter().
[protected]
bool QObject::isSignalConnected(const QMetaMethod &signal) const
Returns true
if the signal is connected to at least one receiver, otherwise returns false
.
signal must be a signal member of this object, otherwise the behaviour is undefined.
static const QMetaMethod valueChangedSignal = QMetaMethod::fromSignal(&MyObject::valueChanged); if (isSignalConnected(valueChangedSignal)) { QByteArray data; data = get_the_value(); // expensive operation emit valueChanged(data); }
As the code snippet above illustrates, you can use this function to avoid emitting a signal that nobody listens to.
Warning: This function violates the object-oriented principle of modularity. However, it might be useful when you need to perform expensive initialization only if something is connected to a signal.
This function was introduced in Qt 5.0.
void QObject::killTimer(int id)
Kills the timer with timer identifier, id.
The timer identifier is returned by startTimer() when a timer event is started.
See also timerEvent() and startTimer().
void QObject::moveToThread(QThread *targetThread)
Changes the thread affinity for this object and its children. The object cannot be moved if it has a parent. Event processing will continue in the targetThread.
To move an object to the main thread, use QApplication::instance() to retrieve a pointer to the current application, and then use QApplication::thread() to retrieve the thread in which the application lives. For example:
myObject->moveToThread(QApplication::instance()->thread());
If targetThread is zero, all event processing for this object and its children stops.
Note that all active timers for the object will be reset. The timers are first stopped in the current thread and restarted (with the same interval) in the targetThread. As a result, constantly moving an object between threads can postpone timer events indefinitely.
A QEvent::ThreadChange event is sent to this object just before the thread affinity is changed. You can handle this event to perform any special processing. Note that any new events that are posted to this object will be handled in the targetThread.
Warning: This function is not thread-safe; the current thread must be same as the current thread affinity. In other words, this function can only "push" an object from the current thread to another thread, it cannot "pull" an object from any arbitrary thread to the current thread.
See also thread().
QVariant QObject::property(const char *name) const
Returns the value of the object's name property.
If no such property exists, the returned variant is invalid.
Information about all available properties is provided through the metaObject() and dynamicPropertyNames().
See also setProperty(), QVariant::isValid(), metaObject(), and dynamicPropertyNames().
[protected]
int QObject::receivers(const char *signal) const
Returns the number of receivers connected to the signal.
Since both slots and signals can be used as receivers for signals, and the same connections can be made many times, the number of receivers is the same as the number of connections made from this signal.
When calling this function, you can use the SIGNAL()
macro to pass a specific signal:
if (receivers(SIGNAL(valueChanged(QByteArray))) > 0) { QByteArray data; get_the_value(&data); // expensive operation emit valueChanged(data); }
Warning: This function violates the object-oriented principle of modularity. However, it might be useful when you need to perform expensive initialization only if something is connected to a signal.
See also isSignalConnected().
void QObject::removeEventFilter(QObject *obj)
Removes an event filter object obj from this object. The request is ignored if such an event filter has not been installed.
All event filters for this object are automatically removed when this object is destroyed.
It is always safe to remove an event filter, even during event filter activation (i.e. from the eventFilter() function).
See also installEventFilter(), eventFilter(), and event().
[protected]
QObject *QObject::sender() const
Returns a pointer to the object that sent the signal, if called in a slot activated by a signal; otherwise it returns 0. The pointer is valid only during the execution of the slot that calls this function from this object's thread context.
The pointer returned by this function becomes invalid if the sender is destroyed, or if the slot is disconnected from the sender's signal.
Warning: This function violates the object-oriented principle of modularity. However, getting access to the sender might be useful when many signals are connected to a single slot.
Warning: As mentioned above, the return value of this function is not valid when the slot is called via a Qt::DirectConnection from a thread different from this object's thread. Do not use this function in this type of scenario.
See also senderSignalIndex().
[protected]
int QObject::senderSignalIndex() const
Returns the meta-method index of the signal that called the currently executing slot, which is a member of the class returned by sender(). If called outside of a slot activated by a signal, -1 is returned.
For signals with default parameters, this function will always return the index with all parameters, regardless of which was used with connect(). For example, the signal destroyed(QObject *obj = 0)
will have two different indexes (with and without the parameter), but this function will always return the index with a parameter. This does not apply when overloading signals with different parameters.
Warning: This function violates the object-oriented principle of modularity. However, getting access to the signal index might be useful when many signals are connected to a single slot.
Warning: The return value of this function is not valid when the slot is called via a Qt::DirectConnection from a thread different from this object's thread. Do not use this function in this type of scenario.
This function was introduced in Qt 4.8.
See also sender(), QMetaObject::indexOfSignal(), and QMetaObject::method().
void QObject::setParent(QObject *parent)
Makes the object a child of parent.
See also parent() and children().
bool QObject::setProperty(const char *name, const QVariant &value)
Sets the value of the object's name property to value.
If the property is defined in the class using Q_PROPERTY then true is returned on success and false otherwise. If the property is not defined using Q_PROPERTY, and therefore not listed in the meta-object, it is added as a dynamic property and false is returned.
Information about all available properties is provided through the metaObject() and dynamicPropertyNames().
Dynamic properties can be queried again using property() and can be removed by setting the property value to an invalid QVariant. Changing the value of a dynamic property causes a QDynamicPropertyChangeEvent to be sent to the object.
Note: Dynamic properties starting with "_q_" are reserved for internal purposes.
See also property(), metaObject(), dynamicPropertyNames(), and QMetaProperty::write().
int QObject::startTimer(int interval, Qt::TimerType timerType = Qt::CoarseTimer)
Starts a timer and returns a timer identifier, or returns zero if it could not start a timer.
A timer event will occur every interval milliseconds until killTimer() is called. If interval is 0, then the timer event occurs once every time there are no more window system events to process.
The virtual timerEvent() function is called with the QTimerEvent event parameter class when a timer event occurs. Reimplement this function to get timer events.
If multiple timers are running, the QTimerEvent::timerId() can be used to find out which timer was activated.
Example:
class MyObject : public QObject { Q_OBJECT public: MyObject(QObject *parent = 0); protected: void timerEvent(QTimerEvent *event) override; }; MyObject::MyObject(QObject *parent) : QObject(parent) { startTimer(50); // 50-millisecond timer startTimer(1000); // 1-second timer startTimer(60000); // 1-minute timer using namespace std::chrono; startTimer(milliseconds(50)); startTimer(seconds(1)); startTimer(minutes(1)); // since C++14 we can use std::chrono::duration literals, e.g.: startTimer(100ms); startTimer(5s); startTimer(2min); startTimer(1h); } void MyObject::timerEvent(QTimerEvent *event) { qDebug() << "Timer ID:" << event->timerId(); }
Note that QTimer's accuracy depends on the underlying operating system and hardware. The timerType argument allows you to customize the accuracy of the timer. See Qt::TimerType for information on the different timer types. Most platforms support an accuracy of 20 milliseconds; some provide more. If Qt is unable to deliver the requested number of timer events, it will silently discard some.
The QTimer class provides a high-level programming interface with single-shot timers and timer signals instead of events. There is also a QBasicTimer class that is more lightweight than QTimer and less clumsy than using timer IDs directly.
See also timerEvent(), killTimer(), and QTimer::singleShot().
QThread *QObject::thread() const
Returns the thread in which the object lives.
See also moveToThread().
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
QObject::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.
QObject::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.
QObject::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.
QObject::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.
QObject::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.
QObject::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.
QObject::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 = 0); ~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.
QObject::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.
QObject::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.
For example, in QLibrary, the LoadHints flag is declared in the following way:
class QLibrary : public QObject { Q_OBJECT public: ... enum LoadHint { ResolveAllSymbolsHint = 0x01, ExportExternalSymbolsHint = 0x02, LoadArchiveMemberHint = 0x04 }; Q_DECLARE_FLAGS(LoadHints, LoadHint) Q_FLAG(LoadHints) ... }
The declaration of the flags themselves is performed in the public section of the QLibrary class itself, using the Q_DECLARE_FLAGS() macro.
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.
QObject::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.
QObject::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.
QObject::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.
QObject::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.
QObject::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.
This function was introduced in Qt 5.8.
QObject::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.
QObject::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])
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.
QObject::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().
QObject::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().
QObject::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.
QObject::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.
QObject::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.
QObject::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.