QAbstractItemModel & QThread [Solved]

[gaijinpunch]

Hi

I've made a handful of read-only classes that inherit QAbstractTableModel. I'm about to do my first editable one. There's a good chance that multiple views will be in their own QThreads... and that a separate thread (3rd party library) might actually update the model as well.

I'm curious about a few things. For starters, there are 4 member functions of QStyledItemDelegate which need to be reimplemented to allow the model to be updated graphically. I'm using the argument (const QModelIndex&) in each of these to determine what type of widget to to create ,and also where to put the data. If the model changes between these calls, is the index still pointing to the one that needs to be chagned? I would think not. Do I need to to come up w/ my own fancy way of keeping track of which index to update? Do I need to deal w/ a mutex locker when calling setModelData()?

[SGaist]

Hi,

Multiple view in their own thrown thread ? Are you thinking of using widget in secondary threads ?

As for you secondary question, the index validity will depend on how the model is changed. But anyway, like always when thread are in the game, you have to protect the access to the data that you are accessing. Mutex or read/write lock it's up to you to decide what suits the best.

[gaijinpunch]

I was imagining a design in which multiple QDialog's were spawned off of a central one in the GUI loop. So that's not going to happen, no? I suppose if I'm inheriting a 3rd party class which does some magic under the sheets, I inheriting that in some type of QObject (not QWidget) and then putting that in it's own QThread is a better design?

EDIT: Do I even need to do that? If I have a QObject like a subclassed QAbstractTableModel which is also inheriting something like MyColleaguesLibrary which runs multiple pthreads and calls a callback every time the data is updated, should I even bother w/ QThread? In this case, the 3rd party library is probably using pthread, but could also be single-threaded I suppose.

[SGaist]

No problem spawning QDialogs from another widget, it's spawning QDialog from a secondary thread that's not possible.

That design decision will depend on how your third party library works and what it does

[gaijinpunch]

Cool -- thanks.

[SGaist]

You're welcome !

If this answers your questions, then please update the thread title prepending [solved] so other forum users may know a solution has been found :)