by admin

Qt Signal Slot Different Class

  1. Qt Signal Slot Different Classic
  2. Qt Signal Slot Performance
  3. Qt Connect Signal Slot
  4. Qt Signal Slot Parameter
  5. Qt Connect Signal Slot Another Class
  6. Qt Signal Slot Thread
  7. Qt Signal Slot Different Classical

Introduction

Signals and slots¶. In Qt, signals and slots are a way for objects to communicate with eachother. A signal is emitted when some event occurs in the program. For example, when a button on the UI is pushed, the button (a QPushButton widget) notifys the other widgets and objects about this by emitting a signal (emit clicked).A slot is a function called as a response to an emitted signal. The connection mechanism uses a vector indexed by signals. But all the slots waste space in the vector and there are usually more slots than signals in an object. So from Qt 4.6, a new internal signal index which only includes the signal index is used. While developing with Qt, you only need to know about the absolute method index. It would be possible to have the slots to which the resized and moved signals are connected check the new position or size of the circle and respond accordingly, but it's more convenient and requires less knowledge of circles by the slot functions if the signal that is sent can include that information. Each PyQt widget, which is derived from QObject class, is designed to emit ‘ signal ’ in response to one or more events. The signal on its own does not perform any action. Instead, it is ‘connected’ to a ‘ slot ’. The slot can be any callable Python function. A slot is a function called as a response to an emitted signal. For example, a slot findClicked is executed as a response to a button click. All subclasses of QObject or one of its subclasses can contain signals and slots. In practice, two things are required for the signal and slot mechanism to work. All classes that contain signals or slots.

Remember old X-Windows call-back system? Generally it isn't type safe and flexible. There are many problems with them. Qt offers a new event handling system: signal-slot connections. Imagine an alarm clock. When alarm is ringing, a signal is being sent (emit). And you're handling it in a slot.

  • Every QObject class may have as many signals and slots as you want
  • You can emit signals only from within that class, where the signal is located
  • You can connect signal with another signal (make chains of signals);
  • Every signal and slot can have unlimited count of connections with other.
  • ATTENTION! You can't set default value in slot attributes e.g. void mySlot(int i = 0);

Connection

Signal

You can connect signal with this template:

QObject::connect (

);

You have to wrap const char * signal and const char * method into SIGNAL() and SLOT() macros.

And you also can disconnect signal-slot:

QObject::disconnect (

);

Deeper

Qt Signal Slot Different Classic

Widgets emit signals when events occur. For example, a button will emit a clicked signal when it is clicked. A developer can choose to connect to a signal by creating a function (a slot) and calling the connect() function to relate the signal to the slot. Qt's signals and slots mechanism does not require classes to have knowledge of each other, which makes it much easier to develop highly reusable classes. Since signals and slots are type-safe, type errors are reported as warnings and do not cause crashes to occur.

For example, if a Quit button's clicked() signal is connected to the application's quit() slot, a user's click on Quit makes the application terminate. In code, this is written as

connect(button, SIGNAL (clicked()), qApp, SLOT (quit()));

Connections can be added or removed at any time during the execution of a Qt application, they can be set up so that they are executed when a signal is emitted or queued for later execution, and they can be made between objects in different threads.

The signals and slots mechanism is implemented in standard C++. The implementation uses the C++ preprocessor and moc, the Meta Object Compiler, included with Qt. Code generation is performed automatically by Qt's build system. Developers never have to edit or even look at the generated code.

In addition to handling signals and slots, the Meta Object Compiler supports Qt's translation mechanism, its property system, and its extended runtime type information. It also makes runtime introspection of C++ programs possible in a way that works on all supported platforms.

To make moc compile the meta object classes don't forget to add the Q_OBJECT macro to your class.

Retrieved from 'https://wiki.qt.io/index.php?title=How_to_Use_Signals_and_Slots&oldid=13989'

The one thing that confuses the most people in the beginning is the Signal & Slot mechanism of Qt. But it’s actually not that difficult to understand. In general Signals & Slots are used to loosely connect classes. Illustrated by the keyword emit, Signals are used to broadcast a message to all connected Slots. If no Slots are connected, the message 'is lost in the wild'. So a connection between Signals & Slots is like a TCP/IP connection with a few exceptions, but this metaphor will help you to get the principle. A Signal is an outgoing port and a Slot is an input only port and a Signal can be connected to multiple Slots.

Qt Signal Slot Performance

For me one of the best thins is, that you don’t have to bother with synchronization with different threads. For example you have one QObject that’s emitting the Signal and one QObject receiving the Signal via a Slot, but in a different thread. You connect them via QObject::connect(...) and the framework will deal with the synchronization for you. But there is one thing to keep in mind, if you have an object that uses implicitly sharing (like OpenCV’s cv::Mat) as parameter, you have to deal with the synchronization yourself.The standard use-case of Signals & Slots is interacting with the UI from the code while remaining responsive. This is nothing more than a specific version of 'communicating between threads'.Another benefit of using them is loosely coupled objects. The QObject emitting the Signal does not know the Slot-QObject and vice versa. This way you are able to connect QObjects that are otherwise only reachable via a full stack of pointer-calls (eg. this->objA->...->objZ->objB->recieveAQString()). Alone this can save you hours of work if someone decides to change some structure, eg. the UI.

Right now I only mentioned Signal- & Slot-methods. But you are not limited to methods - at least on the Slots side. You can use lambda functions and function pointers here. This moves some of the convenience from languages like Python or Swift to C++.

For some demonstrations I will use the following classes:

Using Connections

To connect a Signal to a Slot you can simply call QObject::connect(a, &AObject::signalSometing, b, &BObject::recieveAQString) or QObject::connect(a, SIGNAL(signalSometing(QString), b, SLOT(recieveAQString(QString)) if you want to use the 'old' syntax. The main difference is, if you use the new syntax, you have compile-time type-checking and -converting. But one big advantage of the 'old' method is that you don’t need to bother with inheritance and select the most specialized method.Lambdas can be a very efficient way of using Signals & Slots. If you just want to print the value, e.g. if the corresponding property changes, the most efficient way is to use lambdas. So by using lambdas you don’t have to blow up your classes with simple methods. But be aware, that if you manipulate any object inside the lambda you have to keep in mind, that synchronization issues (in a multithreaded environment) might occur.

You will get an idea of how to use the different methods in the following example:

As you see, recived a QString: 'Hello' is printed two times. This happens because we connected the same Signals & Slots two times (using different methods). In the case, you don’t want that, you see some methods to prohibit that and other options in the next section Connection Types.

One side note: if you are using Qt::QueuedConnection and your program looks like the following example, at some point you will probably wonder, why calling the Signal will not call the Slots until app.exec() is called. The reason for this behavior is that the event queue, the Slot-call is enqueued, will start with this call (and block until program exits).

And before we start with the next section here is a little trick to call a method of another thread inside the context of the other thread. This means, that the method will be executed by the other thread and not by the 'calling' one.

Qt Connect Signal Slot

To learn more about that here is your source of truth: https://doc.qt.io/qt-5/qmetamethod.html#invoke

Connection Types

Qt::AutoConnection

Qt::AutoConnection is the default value for any QObject::connect(...) call. If both QObjects that are about to be connected are in the same thread, a Qt::DirectConnection is used. But if one is in another thread, a Qt::QueuedConnection is used instead to ensure thread-safety. Please keep in mind, if you have both QObjects in the same thread and connected them the connection type is Qt::DirectConnection, even if you move one QObject to another thread afterwards. I generally use Qt::QueuedConnection explicitly if I know that the QObjects are in different threads.

Qt::DirectConnection

A Qt::DirectConnection is the connection with the most minimal overhead you can get with Signals & Slots. You can visualize it that way: If you call the Signal the method generated by Qt for you calls all Slots in place and then returns.

Qt::QueuedConnection

The Qt::QueuedConnection will ensure that the Slot is called in the thread of the corresponding QObject. It uses the fact, that every thread in Qt (QThread) has a Event-queue by default. So if you call the Signal of the QObject the method generated by Qt will enqueue the command to call the Slot in the Event-queue of the other QObjects thread. The Signal-method returns immediately after enqueuing the command. To ensure all parameters exist within the other threads scope, they have to be copied. The meta-object system of Qt has to know all of the parameter types to be capable of that (see qRegisterMetaType).

Qt::BlockingQueuedConnection

A Qt::BlockingQueuedConnection is like a Qt::QueuedConnection but the Signal-method will block until the Slot returns. If you use this connection type on QObjects that are in the same thread you will have a deadlock. And no one likes deadlocks (at least I don’t know anyone).

Qt::UniqueConnection

Qt::UniqueConnection is not really a connection type but a modifier. If you use this flag you are not able to connect the same connection again. But if you try it QObject::connect(...) will fail and return false.

This is not everything you will ever need to know about Signals & Slots but with this information you can cover about 80% of all use-cases (in my opinion).If it happens and you need the other 20% of information, I’ll give you some good links to search your specific problem on:

Qt Signal Slot Parameter

The Qt documentation:

Qt Connect Signal Slot Another Class

Very deep understanding:

Qt Signal Slot Thread

Part1: https://woboq.com/blog/how-qt-signals-slots-work.html

Qt Signal Slot Different Classical

Part2: https://woboq.com/blog/how-qt-signals-slots-work-part2-qt5.html

Part3: https://woboq.com/blog/how-qt-signals-slots-work-part3-queuedconnection.html

< previous step index next step >