Qt Signal Slot Call Order
Signals and slots are loosely coupled: a class which emits a signal neither knows nor cares which slots receive the signal. Qt's signals and slots mechanism ensures that if you connect a signal to a slot, the slot will be called with the signal's parameters at the right time. Signals and slots can take any number of arguments of any type. Signals and Slots. The most important features of Qt are signals and slots. Signals tell you that something has just happened. Signals are emitted (sent) when the user works with the computer. For example, when the user clicks the mouse or presses keys on a keyboard a signal is emitted.
@JonB said in Can a signal call a non-slot method: @SGaist. Nothing Qt 5 specific, these macros have the same functionality since the beginning. Before Qt5 signals was protected, now it is public (to allow new connection syntax). That was why I wrote Qt5+. 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 as the order the connection was made, when the signal is emitted. The function returns true if it successfully connects the signal to the slot.
- PyQt Tutorial
- PyQt Useful Resources
- Selected Reading
Unlike a console mode application, which is executed in a sequential manner, a GUI based application is event driven. Functions or methods are executed in response to user’s actions like clicking on a button, selecting an item from a collection or a mouse click etc., called events.
Widgets used to build the GUI interface act as the source of such events. 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.
In PyQt, connection between a signal and a slot can be achieved in different ways. Following are most commonly used techniques −
A more convenient way to call a slot_function, when a signal is emitted by a widget is as follows −
Suppose if a function is to be called when a button is clicked. Here, the clicked signal is to be connected to a callable function. It can be achieved in any of the following two techniques −
or
Example
In the following example, two QPushButton objects (b1 and b2) are added in QDialog window. We want to call functions b1_clicked() and b2_clicked() on clicking b1 and b2 respectively.
When b1 is clicked, the clicked() signal is connected to b1_clicked() function
When b2 is clicked, the clicked() signal is connected to b2_clicked() function
Example
The above code produces the following output −
Output
I wrote about multi-threading in Qt a while back, and how to use QThread to wrap a blocking function call “lock free”. Today we’ll talk about how to pass data into your thread. This approach can be used, for example, to tell your QThread to stop.
There are two ways to use QThread, with and without an event loop, and the preferred method for talking to a QThread depends on which of them you use.
Way 1: Without an event loop
When you’re not using an event loop, the thread’s run() method often looks like this:
Since this method does not use an event loop, there is no way to deliver a signal to your thread. So if you want to pass data into the thread, you have to use a good old fashioned mutex. Let’s look at an example showing you how to stop your thread:
In this case, we have to check the stopRequested variable in a timely manner in our thread’s run() method. The longer you run between checks, the longer it will take your thread to actually stop.
Outside observers can use the finished() signal to know when your thread is actually done. So if you are in a QMainWindow, for example, and a closeEvent() happens, you can ignore the event, call MyThread::stop(), and then when the QThread::finished() signal arrives, you can actually close the window.
The downside is that the stop() call will actually block while it tries to acquire the mutex. Given the way this code is written, the blocking will probably be very short, but hey, I hate blocking. Let’s see if we can dig up a better way to do this.
Qt Signal Slot Call Orders
Way 2: With an event loop
If you have an event loop, you can use Qt’s meta-objects to talk to your thread. Let’s look at the same example as before, only this time with no locking or blocking.
Look mom! No locks! Now we have killed our thread, safely and gracefully. There is no chance of blocking, and we learned something about QMetaObject.
Qt Signal Slot Call Ordering
A couple items to note:
- The doSomething() method is left as an exercise for the reader, but be careful about the QTimer interval. I used 0, which means it will be firing almost constantly.
- The stop() method must be a slot in MyThread (and not just a regular method) or else invokeMethod() will return false and not actually re-invoke stop() for you.
- You can pass arguments to your thread this way, but it requires a bit more fun with QMetaObject::invokeMethod().
- You can reduce this whole thing to a magical macro that you could put at the top of your stop() method, saving you from having to write if(currentThread() this) at the top of every method. Hint: use the __FUNCTION__ macro.
- To run this example code, you’ll need to #include these files: QThread, QTimer, QMetaObject, QMutexLocker, and QMutex
- To call quit(), it may not actually be necessary to be running on the same QThread (it works for me without the QMetaObject), but this will be required when you start passing in data to your thread. Without it, your program could do unpredictable naughty things. I can’t find anything in the docs about whether quit() is thread safe.
I’ve found this QMetaObject approach the most effective and easiest way to pass data to QThreads safely, without blocking and without locks.
Happy threading!