I propose to use the QThread instead threading.Thread in this case. It's mostly the same. The main difference is that QThreads are better integrated with Qt (asynchrnous signals/slots, event loop, etc.). Also, you can't use Qt from a Python thread (you can't for instance post event to the main thread through QApplication.postEvent): you need a QThread for that to work. A general rule of thumb might be to use QThreads if you're going to interact somehow with Qt, and use Python threads otherwise.
Edited 5 Years Ago by nabla2. Of course, you can.
Open the search bar. Touch Install. Enter 'Yahoo Mail' in the search bar at the top and then touch Yahoo Mail in the pop-up auto-suggest list. Free download yahoo messenger for samsung galaxy y duos. Touch Play Store.
Read example carefully. You need a class that inherits from QThread and implements the run method, which is triggered by start. For communication between the thread and the GUI use the signals and slots. At first it may be complicated. Writing multithreaded programs requires a bit more knowledge, regardless of whether you are using PyGTK, wxPython, etc. PyQt is probably the best choice (in my opinion).
It emits signals to indicate that the thread started or finished executing, and provides a few slots as well. More interesting is that s can be used in multiple threads, emit signals that invoke slots in other threads, and post events to objects that 'live' in other threads. This is possible because each thread is allowed to have its own event loop. QObject Reentrancy is reentrant.
Most of its non-GUI subclasses, such as, and, are also reentrant, making it possible to use these classes from multiple threads simultaneously. Note that these classes are designed to be created and used from within a single thread; creating an object in one thread and calling its functions from another thread is not guaranteed to work.
There are three constraints to be aware of:. The child of a must always be created in the thread where the parent was created. This implies, among other things, that you should never pass the object ( this) as the parent of an object created in the thread (since the object itself was created in another thread).
Event driven objects may only be used in a single thread. Specifically, this applies to the and the. For example, you cannot start a timer or connect a socket in a thread that is not the. You must ensure that all objects created in a thread are deleted before you delete the. This can be done easily by creating the objects on the stack in your implementation. Although is reentrant, the GUI classes, notably and all its subclasses, are not reentrant. They can only be used from the main thread.
As noted earliermust also be called from that thread. In practice, the impossibility of using GUI classes in other threads than the main thread can easily be worked around by putting time-consuming operations in a separate worker thread and displaying the results on screen in the main thread when the worker thread is finished. This is the approach used for implementing the and the example. Per-Thread Event Loop Each thread can have its own event loop. The initial thread starts its event loops using ; other threads can start an event loop using. Like, provides an (int) function and a slot.
An event loop in a thread makes it possible for the thread to use certain non-GUI Qt classes that require the presence of an event loop (such as, and ). It also makes it possible to connect signals from any threads to slots of a specific thread. This is explained in more detail in the section below. A instance is said to live in the thread in which it is created. Events to that object are dispatched by that thread's event loop. The thread in which a lives is available using.
Note that for that are created beforereturns zero. This means that the main thread will only handle posted events for these objects; other event processing is not done at all for objects with no thread. Use the function to change the thread affinity for an object and its children (the object cannot be moved if it has a parent). Calling delete on a from a thread other than the one that owns the object (or accessing the object in other ways) is unsafe, unless you guarantee that the object isn't processing events at that moment.
Use instead, and a event will be posted, which the event loop of the object's thread will eventually pick up. By default, the thread that owns a is the thread that creates the, but not after has been called. If no event loop is running, events won't be delivered to the object. For example, if you create a object in a thread but never call, the will never emit its signal. Calling won't work either.
(These restrictions apply to the main thread as well.) You can manually post events to any object in any thread at any time using the thread-safe function. The events will automatically be dispatched by the event loop of the thread where the object was created. Event filters are supported in all threads, with the restriction that the monitoring object must live in the same thread as the monitored object. Similarly(unlike ) can only be used to dispatch events to objects living in the thread from which the function is called. Accessing QObject Subclasses from Other Threads and all of its subclasses are not thread-safe. This includes the entire event delivery system.
It is important to keep in mind that the event loop may be delivering events to your subclass while you are accessing the object from another thread. If you are calling a function on an subclass that doesn't live in the current thread and the object might receive events, you must protect all access to your subclass's internal data with a mutex; otherwise, you may experience crashes or other undesired behavior. Like other objects, objects live in the thread where the object was created - not in the thread that is created when is called. It is generally unsafe to provide slots in your subclass, unless you protect the member variables with a mutex.
On the other hand, you can safely emit signals from your implementation, because signal emission is thread-safe. Signals and Slots Across Threads Qt supports these signal-slot connection types:. (default) If the signal is emitted in the thread which the receiving object has affinity then the behavior is the same as the Direct Connection. Otherwise, the behavior is the same as the Queued Connection.' . The slot is invoked immediately, when the signal is emitted. The slot is executed in the emitter's thread, which is not necessarily the receiver's thread.
The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread. The slot is invoked as for the Queued Connection, except the current thread blocks until the slot returns.
Note: Using this type to connect objects in the same thread will cause deadlock. The behavior is the same as the Auto Connection, but the connection is made only if it does not duplicate an existing connection.
I.e., if the same signal is already connected to the same slot for the same pair of objects, then the connection is not made and connect returns false. The connection type can be specified by passing an additional argument to. Be aware that using direct connections when the sender and receiver live in different threads is unsafe if an event loop is running in the receiver's thread, for the same reason that calling any function on an object living in another thread is unsafe. itself is thread-safe. The example uses a queued connection to communicate between a worker thread and the main thread. To avoid freezing the main thread's event loop (and, as a consequence, the application's user interface), all the Mandelbrot fractal computation is done in a separate worker thread. The thread emits a signal when it is done rendering the fractal.
Similarly, the example uses a separate thread for communicating with a TCP server asynchronously. Previous: Next:. © 2008-2010 Nokia Corporation and/or its subsidiaries. Nokia, Qt and their respective logos are trademarks of Nokia Corporation in Finland and/or other countries worldwide. All other trademarks are property of their respective owners. Licensees holding valid Qt Commercial licenses may use this document in accordance with the Qt Commercial License Agreement provided with the Software or, alternatively, in accordance with the terms contained in a written agreement between you and Nokia. Alternatively, this document may be used under the terms of the as published by the Free Software Foundation.
A lot of the reasoning behind the (mis)use of QThread in the Qt documentation is, I believe, left over from the way things were done in Qt 3. I could be wrong.
As one of the perpetrators of the “wrong” way of doing things, I wish there could be a better discussion of both approaches in the documentation because it seems to me that each approach has its merits. Hopefully, the Qt Project effort will help get updates on subjects like these into the regular documentation, though this ultimately depends on having enough people with commit rights and available time to review and merge them into the mainline Qt tree.
If you’re the sort of person who’s motivated to do that then I’d urge you to get involved in the project, or perhaps even to get hired as a writer: Disclaimer: I worked there until earlier this year. I have one little worry here, which is a technical detail easilly overlooked. I know that deleteLater works by creating an event on the objects event loop, which will delete it when the event queue gets to it.
The quit on the thread is implemented in the same way, an event on the queue. And in this case its the same queue.
So my worry is that the quit is executed before the deleteLater is executed and we have a leak. One easy solution might be that you don’t connect the finished to the threads quit, instead you connect the workers destroyed to the threads quit. One more thing that might be useful to add here is how to properly delete stuff if the user wants the app to quit before the finished is emitted. How to delete the thread properly. This typically means that someone in the gui thread calls quit and then wait on the thread object. Thanks for the blog, excellent summary and overview.
Hi Thomas, The intention is for quit to be executed before deleteLater. As a serial queue is used there should be no issue here. As for the rest of your worries, do you mean connecting the finished signal to deleteLater, and instead connecting the thread’s terminated signal upon terminating (as a result of quit) to deleteLater? That might work, but I haven’t tried it nor do I know whether it has any benefits.
This also ties in with calling quit on the thread directly. There’s no real need to dispose of the thread and wait for its exit unless you’re dealing with a program termination. Ah, I see my mistake; I’ve not explained which deleteLater I’m talking about ? I think the issue is still there, and my explanation is easy to misread, and I see you commented on something slightly different. Mind if I try again?
What this starts with is that there are two connects with the SLOT(deleteLater) in them. Those two connects are handled by two different event queues. The first is on the worker object and due to its moveToThread its handled in the event queue of the ‘thread’ object. The second is handled by the main QApplication event queue. The worry I’m having is that this is happening;.
worker emits finished. This causes 1) a new ‘please-quit’ event to be placed on the threads event queue. 2) a new ‘delete worker’ event to be placed on the threads event queue. 3) a new ‘delete thread’ event to be placed on the main-gui event loop. The correct order of execution here is ‘delete worker’, ‘exit thread event-loop’ and last ‘delete thread’. In Qt docs I’ve seen often mentioned that the order in which slots are executed is not deterministic. So my numbering of 1,2,3 is not a well-defined order.
Then there is the fact that this is spread over two threads and the order can be changed due to that too. So, in short, I worry that due to event ordering not being enforced we might leak the ‘worker’ object. I think I get thomaszander’s concern, for I share it. Let me try to put it this way.
In the example code line: connect(worker, SIGNAL(finished), worker, SLOT(deleteLater)); This posts an event into the worker thread’s queue to delete the qthread object, when the qthread has finished. But if the thread truly has finished, it doesn’t have an event loop no more, doesn’t consume the deleteLater event, and thus, don’t get deleted. My assumption is, that due to a race condition 1 inside the QThreadPrivate::finish, the code works however. It works at least in Qt 4.7, but it might not work in the future versions of QThread. If I understood it correctly, qhtread::finished signal is emitted on the thread’s context (direct call to qhtreadprivate::finish), so in fact, the qthread is not finished when finished is emitted. Issue is discussed here: 1.
I am forever in your debt, Maya. It is really hard to understand why Qt does not properly document such an important matter. And a tricky one, your optimism notwithstanding. If you could enlighten us a little further about thread-local data issues I’d be even more grateful.
The Qt code around moveToThread kind of looks to me like it is meant to transfer heap data to the new thread — but I don’t understand this at all well. Then there is the little matter of terminating a thread synchronously and restarting it. Qt docs say QThread::wait is equivalent to Unix join. I have been using it where I want to stop and restart some loops that run in threads, and the results so far have been hung GUI thread and/or failure of the restarted loop. Have you an example of how to do this right? This might be related to the concerns some people had further up about the enqueuing of the `deleteLater` events. I’m trying to employ this method in Qt 4.8.3, but the code as presented in this example reproducibly leads to an access violation as soon as the QThread’s event loop gets around to consume the `deleteLater` event.
It seems that after executing the QThread’s `quit` function, Qt is about to auto-delete the QThread object, but it is still in some sort of limbo state where the next event, `deleteLater`, is still consumed, to which it doesn’t take well. The same happens when trying to do a `delete thread;` after using `thread-quit; thread-wait;`, the application will throw an access violation on the delete. I’m not sure if Qt actually garbage-collects these and I’m fine, or whether I’m leaking QThreads by omitting the delete/deleteLater; but if I am, I don’t know how to clean them up since any which way I try crashes my application.
Qt Update Gui From Threads 1
Considering it’s the `delete` itself that crashes seems to suggest it’s already been deleted though, right? (Unless the pointer was modified, which it wasn’t). : This might be related to the concerns some people had further up about the enqueuing of the `deleteLater` events. I’m trying to employ this method in Qt 4.8.3, but the code as presented in this example reproducibly leads to an access violation as soon as the QThread’s event loop gets around to consume the `deleteLater` event. After executing qthread::quit, your qthread exits it’s event loop, and should not be sent any (not even deleteLater events).
What if you, before exiting the qthread context – move you “qobject” back to main thread for deletion, where you still have a running event loop? After “processing”, call this-movetothread(qcoreapplication::instance-thread).: It seems that after executing the QThread’s `quit` function, Qt is about to auto-delete the QThread object, but it is still in some sort of limbo state where the next event, `deleteLater`, is still consumed, to which it doesn’t take well. The same happens when trying to do a `delete thread;` after using `thread-quit; thread-wait;`, the application will throw an access violation on the delete. I’m not sure if Qt actually garbage-collects these and I’m fine, or whether I’m leaking QThreads by omitting the delete/deleteLater; but if I am, I don’t know how to clean them up since any which way I try crashes my application. Considering it’s the `delete` itself that crashes seems to suggest it’s already been deleted though, right? (Unless the pointer was modified, which it wasn’t). I don’t think Qt garbage collects anything here – for these objects don’t have a parent.
Qt only deletes a qobject’s children. In fact, in order for the qobject::movetothread to work, the object must not have parent (apparently to avoid this garbage collector to delete the object from another thread’s contect). Thanks Maya, I have spent a good week trying to solve the very same problem using the sub-classing method discussed in my study material. It worked for a while and then suddenly I got dumps and unexpected failures in my code. After changing to the method discussed here and actualy finding that it is documented QT4.8 documentation, it started to work as expected.
“Using the combination of these two references I got the multithreaded applicaton to work without any issues. I do have one question, I have long running threads and it seems like my application is then non responsive. I then tried calling the Qapplication::processEvents method which I thaught would work simular to Microsofts doEvents which should make the application responsive but it makes it only run longer. The question is, where do have to add Qapplication::processEvents or what is the most appropriate place to use this method. Hello Maya, you mention that one should never allocate heap memory in the Object (probably referring to the worker. This may be easily achieve in some applications. My main application needs to allocate quite big resources (many GBs of RAM through NVIDIA mallocHost, mmap’d kernel memory, etc) at the very beginning which are shared across several threads performing work.
If I used your approach, all my workers would still have to have references to objects created in the main thread, and of moveToThread of the workers will move themselves to the target thread, but not the objects they contain and work on. How would you go about that?
Cheers, peter. Quote from above: “By the way, one extremely important thing to note here is that you should NEVER allocate heap objects (using new) in the constructor of the QObject class as this allocation is then performed on the main thread and not on the new QThread instance, meaning that the newly created object is then owned by the main thread and not the QThread instance. This will make your code fail to work. ” IMHO the above statement is NOT true if we use a worker QObject and then moveToThread properly and the heap objects are children of that worker QObject. Maybe the warning only applies to the case where people subclass QThread???
Please correct me if I’m wrong. Following on from the posts above. I’ve spent most of today trying to track down an illusive memory leak in a component i have written to push Pixmap images to a fileshare on its own thread. Turns out it was because of the concerns raised above with deleteLater, using Glowcode to profile my memory usage i found that something was holding a Shared memory reference to the pixmap after everything had been completed. I tracked this down to a QObject i was constructing and pushing onto a worker thread. Granted, it would work 95 out of 100 runs.
But the other 5%of the time the QObject would not be destroyed. I’ve adjusted to using: connect(mpMoveImageToFileShare, SIGNAL(destroyed), mpWorkerThread, SLOT(quit), Qt::QueuedConnection); And profiled it again everything is looking a lot better. So a note to anyone using this implementation, it works the vast majority of the time using the ‘finished’ signal from the object to the ‘quit’ slot on the worker thread but it is not bomb proof! Of course it might seem overkill in the article, but note that it’s about the correct use of QThread and not whether threads or the right solution to whatever problem one is faced with ? Of course a QThreadPool and QRunnables would be more elegant in many cases, yet again this is not what this article is about.
Cases where the use of a QThread is warranted is where one needs a lot of control over the creation, use and disposal of said thread. The Qt documentation also has an article on which type of concurrency to pick depending on the situation. Quote: “you should NEVER allocate heap objects (using new) in the constructor of the QObject class as this allocation is then performed on the main thread and not on the new QThread instance, meaning that the newly created object is then owned by the main thread and not the QThread instance”. I have never tried this but since threads are supposed to all share the same heap (they only have a distinct stack), I don’t see why it wouldn’t work.
Please check your information. Maybe threads have a distinct stack too in Qt but that would be very weird. A great simple example Maya.
I linked to it from a blog entry on my page, but I noticed something that could be of concern. As you know, a mutex must be used between threads sharing data. There is also the problem of sharing Qt implicitly shared objects between threads. I can see that you pass a QString (implicitly shared) from the worker object to the main GUI thread using a signal and slot. While I haven’t looked into the exact implementation of this signal to slot process, I believe you will get a reference to the same QString at both threads.
This means if you modify the QString in one thread while the other is using it, a crash may result. I say may result because it all depends on what code is being executed when the string is modified. The deep copy and reference atomic counting used in implicitly shared objects is not thread safe. It may only crash 1 in 1000 times, but those types of bugs are very hard to find and fix. I covered this issue in this blog entry: The example code I provide is somewhat flawed.
I haven’t done much work on this because I simply avoid making this mistake and pass only safe non-shared objects on a signal to slot transaction. Perhaps some day I will do some more code testing to prove it is a problem.
Hi, Thanks for your great example code. I have tried your code its working fine in my linux mint but I got this error on windows 7: ASSERT failure in QCoreApplication::sendEvent: “Cannot send events to objects owned by a different thread.
Current thread 1d856a78. Receiver ” (of type ‘DataMapperStokAwal’) was created in thread 1bc54568″, file kernel qcoreapplication.cpp, line 514 Invalid parameter passed to C runtime function. Invalid parameter passed to C runtime function. QObject::QObject: Timers cannot be stopped from another thread What should i do?
This is the first time i use thread and database Thanks. For quite some time I’ve been using QThread by subclassing and implementing the virtual run method in the subclass. With this solution the run method of the worker subclass is typically the main method (which is called “process” in the example) of the worker. The alternative of pushing a QObject from its instantiation context to a different QThread affinity (QObject::moveToThread), while an appropriate solution in many cases, also has its limitations. For example, when the application is not using QCoreApplication (or the QApplication subclass). What is missing is an understanding of why a QObject worker process needs to be operating in the “correct” thread affinity context. It’s about the event loop used by the worker object.
The base QObject class uses an event loop to manage deferred signal-slot deliveries and other events, and, being thread aware, will queue signal events on the event loop of the receiving slot object. Thus classes with signals and/or slots need a QObject which in turn needs an event loop that will convey the signal to slots (unless a DirectConnection is being used, in which case no event loop is used). Thread affinity is about which thread will operate the OObject’s event loop. By default a QObject uses the event loop operating in the thread in which it is instantiated. Every application obviously has at least the main thread.
This is where the QApplication is (expected to be) instantiated, and where a GUI application’s main event loop operates when the its exec method is called. A QThread is a QObject subclass.
The QThread is not instantiated in the thread that will be run when it is started, so the slots and signals of the QThread, and any objects it creates outside the context of its run method, will use the event loop operated by the thread where the QThread was instantiated. For QOjects created within the context of its run method signal and slots must be serviced by an event loop operated by the thread that was started for the run method.
The default implementation of the QThread’s protected run method, which is called in QThread’s running thread context by its start method, will call its protected exec method that will operate the QThread event loop to manage slots and signals in the thread context. Implentations of a QThread subclass may call exec in their run method with the understanding that the method will not return until the QThread quit (or exit) method is called. This additional complexity can be avoided by setting the affinity of a QObject (moveToThread) to the desired QThread and using the default implmentation of the run method. Nevertheless, the additional complexity of subclassing QThread and providing a new run method offers significant additional control and sophistication for the operation of the thread process. There are essentially two conceptual solutions for running a new thread: Simple and sophisticated. Choosing which to use will, of course, depend on what the implmentation intends to do.
They are both the same behind the scenes. Note that an application’s address space is shared by all threads of the application. An object (its data) can be accessed across threads. Problems arise when multiple threads attempt unsynchronized access to the same data, regardless of which object is accessed. The heap is an application resource which can be accessed from any thread as any other object. A thread may provide its own stack which, though it can be accessed across threads, is expected to be used for thread local automatic variables to help alieviate re-entrancy problems.
The documentation of Qt thread managment has been significantly enhanced to address many of the issues raised here (see ). However, a thorough grasp of multi-threading requires more than reading the Qt documentation (;-). Dear, First, I must say its a nice tutorial on QThread. In your example, the “process” method emits “finished” signal to stop the thread.
I ran into a situation where I have an infinite loop in the “process” method. The loop updates my data, and uses the same to paint (update) a QWidget. Now, I want to break the loop (or stop the thread) on a button click. I am not sure when to emit “finished” signal because the loop is infinite. Is there a way to send some signal (or put some condition) in the infinite loop to break it and emit “finished”. I guess there could be some tricky use of “connect” to make this happen.
I am stuck and tried different ways. Now, Looking forward to your kind suggestions. Thanks in advance. Hi Maya, I have a long running queue processor that I’m using a custom built thread pool for. I needed it to be custom so that I can do http callouts and get responses within each thread.
When a process completes, I check to see if any of the threads in the pool are idle via the property (“hasWorker”) and if they don’t and theres another image fetch in the queue, than instead of killing the QThread, I re-assign it (“hasWorker”) move another worker object to it and then start the worker. The problem is is that when there is nothing in the queue, as workers complete I’d like to shut down there threads. I am killing my threads via: myThreadPool.removeOne(t); t-quit; t-wait(1000); t-deleteLater; pruneCount; However I’m getting system crashes every once and a while. Could you help me understand the purpose of the wait(x) call — I saw that it was recommended on stack overflow.
Could the issue be that I’m not explicitly calling “start” and “finish” on these threads? Any insights appreciated. My workers are setup like: connect(this, SIGNAL(work(int)), worker, SLOT(doWork(int)), Qt::QueuedConnection); connect(this, &BaseManager::cancel, worker, &BaseWorker::onCancel, Qt::QueuedConnection); connect(worker, &BaseWorker::finished, this, &BaseManager::finished, Qt::QueuedConnection); connect(worker, &BaseWorker::finished, worker, &BaseWorker::deleteLater, Qt::QueuedConnection). This framework works equally well for instances where you need a “catcher” thread that lives for the lifetime of the overall program. Example: I use this framework surrounding a QSerialPort. The worker object owns and opens the serial port and receives work based on the QSerialPort::readyRead; signal. Additionally, I send work from the main object which spawned this thread, to which this worker replies with signals of it’s own, returning simple byte arrays of results or booleans.
So contrary to the militant view that threads should “do one thing and die”, this is a very simple and logical way to manage a DEVICE that is inherently slow even at it’s fastest speeds, is asynchronous in nature and thus is “in the way” in a GUI or in a controller object elsewhere. Using queued signals makes things orderly. Many thanks Maya. This is a great explanation on how to use Qthreads, I have been struggling with how to properly use them for years, using the inheritance and run method. Because this was the only official documentation that I could find.
This new method is really straight forward and makes more sense to me. But I am curious why the inheritance method is wrong? You did not really get into the pros and cons of the two methods. Also you did not mention on how to communicate with the thread, I have threads that operating on data continually and then need to wait for more data to process. I accomplish this with a while loop in the run and a bool flag that data is ready, if no data is ready the while loop just executes sleep.
Using a slot to signal the thread with a payload of data. I haven’t been able to find any definitive answer on how to do this effectively. Do you have a take on this? Thank you for posting this, I have been looking along time on better ways to use QThreads. The inheritance method isn’t necessarily wrong, just that it’s terrible overkill. As pointed out in the article, QThread is a wrapper around an OS-level thread. It’s easiest to just move one’s code onto an instance of this wrapper instead of having to deal with the details of how a QThread is implemented.
Unless one’s need are very specific, naturally, but at that point one might wonder why one is using QThreads to begin with ? Using signals and slots is the usual way to communicate between workers running in a QThread. Qt makes sure that this happens in thread-safe manner. If one needs to have one thread wait for another, one can also look at the use of condition variables and kin.
I actually covered a lot of this (from a C11 focus, though) in my latest book: Mastering C Multithreading.
PyQt update qt labels from another thread PyQt update qt labels from another thread Roberto Alsina Wed Apr 11 13:38:12 BST 2007. Previous message:. Next message:. Messages sorted by: On Wed 11 Apr 2007 09:13:33 Pradnyesh Sawant wrote: HelloI have a Qt4 form, which contains some labels, and 2 buttons 'start' and 'stop'. The start button, when clicked, creates an instance of a python class which does some communication over sockets in another independent thread of its own. The stop button kills the instance created above, and kills the thread.
What i want to do is to update the text of my form labels with the data that i receive over the socket communication. For this reason, i sent the 'form' object to the backend class object, and tried updating the form labels from within the thread doing the socket communication. However, i get an error saying that Qt objects cannot be modified from other threads:( How do i achieve updates of form labels? In a previous mail on this list itself, i read something about signals/slots/callbacks. I don't see how signals/slots will be helpful here (however, plz note that i am relatively new to PyQt4 and this might be incomplete knowledge on my part).
As far as callbacks are concerned, i don't know what they mean. Any pointers/tutorials for me would be greatly helpful. If the answer is 'use signals and slots'. Keep in mind that the code below is written without any testing, and I am not even sure if signals/slots actually work cross-threads in Qt4;-) Suppose the form has a 'setLabelText' function like this: def setLabelText(self,newtext): self.ui.theLabel.setText(newtext) And the 'object in another thread' wants to update it. You need to make that object inherit QtCore.QObject (or use a QSignal object. Those still exist in Qt4, right?) Then the object can do this: emit (QtCore.SIGNAL('newData'),'data') If you previously connected that object's newData signal to the form's setLabelText slot.
You are golden, regardless of on what thread the signal is emitted, I suppose. (' '/').-'`.
Roberto Alsina `9 9 ) `. ( ).`.`) (Y.)'. ) `.`. '.-' KDE Developer (MFCH).`-'.-/ /-'.' (l)-' ((i).'
Buenos Aires - Argentina Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. Kernighan.
Previous message:. Next message:. Messages sorted.
Despite the synchronization overhead, I imagine this approach could avoid crashes. But if the View class you are using can do any autonomous modifications (like drag and drop rearrangement), then it could break the expectations of worker thread code, such as: model-insertRow(0); // Gui could modify model here! Model-setData(model-index(0, 0), subject); // Gui could modify model here! Model-setData(model-index(0, 1), sender); // Gui could modify model here! Model-setData(model-index(0, 2), date).
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |