Mark Summerfield schrieb:
On 2010-04-20, andre hotz wrote:
Mark Summerfield schrieb:
On 2010-04-20, andre hotz wrote:
Hey,
I have a problem with my QThreads (running on windows). It is the first
time I use multithreading, so I am probably doing something wrong ;)
The situation is as follows: I have a QTreeWidget which works like a
filebrowser, listing a few thousand files. Creating
the treeitems from the files is pretty fast, but I also want the
treeWidget to display more information about the files.
This is taking some time depending on the quantity of the files. So
what
I did is to first fill the treeView with all the filenames.
After that, I start an update-threat, which loops through all the items
in the treeWidget, gathers its data and fills the additional
columns in the treeView with the data. While the thread is updating the
treeWidget, the user can already work with the files and does not need
to wait for the update to finish.
This all works pretty well.
I think you've been pretty lucky to have it work at all!
hehe, yeah, I was pretty happy when I got it working the first time ;)
Qt does not provide any means of locking items or views. As a
consequence, Qt does _not_ support updating models, scenes, or items in
models, or items in widgets such as QTreeWidgetItems or
QTableWidgetItems, etc. outside the main (GUI) thread. So any such
update is potentially the source of a crash.
hm, yes, this might explain the crashes..
One technique that could be used is to hold the data in a thread-safe
data structure and read data from that into the GUI as needed (locking
the data structure or each item read from it as needed), and updating
the data from one or more secondary threads (locking as needed).
That sounds like it could work. Would it be possible to hold the data as
you said, but when the update thread is finished, let it emit a signal
to the treeWidget which then updates itself with the given data
structure? Or does emitting signals from another thread also not work?
One of the great things about signals and slots is that they work safely
across threads:-)
So you can certainly emit a signal in a secondary thread that's
connected to a main (GUI) thread slot. And since you can pass values via
signals, if you had simple things like ints, doubles, and QStrings, you
could even call the main thread every time you updated the data on a
single file in the secondary thread (at some cost in performance that
may or may not matter) to give the main thread the info you want.
I just updated my code so it uses signals now and it works way better. I
still got crashes because of the thread.terminate() so I replaced it
with wait() for now, makes things a bit slower, but that's still better
than a crash ;)
So thanks a lot for your help!
Andre
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
