Row Index von QTableWidget ermitteln

[jb_alvarado]

Qt und threading sollten da genug liefern, die originale Dokumentation hat da einiges an Beispielen und Erklaerungen. Und eine Queue ist doch ausreichend, alles, was da reingestopft wird, erledigt irgendwann der Worker-Thread.

Bin da mittlerweile etwas schlauer geworden und ich danke das bekomme ich hin. Mit der Queue ist es bei meinem Fall halt so, dass sich darin immer nur ein Objekt, das aktuelle, drin befinden darf. Habe mir gedacht, dass ich das so lösen könnte, dass mein WorkerThread jedes mal wenn er eine Zeile abgearbeitet hat ein Signal schickt, welches veranlasst dass ein neues Objekt in die Queue geschoben wird.

Signal/Slot-Verbindungen KOENNEN thread-sicher sein, die Bedingungen unter denen das so ist werden in der Dokumentation erklaert, das sind dann sogenannte "Queued Connections". In einem anderen Zusammenhang habe ich dazu mal Beispiele gebaut: viewtopic.php?f=24&t=44250&start=15#p335559

Was ich gelesen habe ist, dass QT wohl automatisch entscheiden kann, wann es welche Art von Verbindung braucht. Ist das immer so?

Und was das Modell angeht: da sprach in von einem QAbstractItem-Model, welches du an deinen View binden kannst, und das damit sauber Daten von Darstellung trennt. Klassisches "Model View Controller"-Pattern halt, wie schon in den 90ern beliebt.

Verstehe jetzt besser warum man das so macht. Habe auch angefangen wieder ein QTableView mit einem QAbstractTableModel zu nehmen. Glücklich bin ich damit allerdings noch gar nicht. Es gibt nicht viel Beispiele im Internet dafür, mein Code wird um einiges komplexer und für die Spinner und Comboboxen brauche ich QItemDelegate um die in die Tabelle zu bekommen.
Weiß echt nicht, ob sich der Aufwand in meinem Fall lohnt. Im Schnitt hat meine Tabelle vielleicht 1-7 Zeilen, wenn's mal hochkommt 20-25.

[__deets__]

Zu Punkt zwei: nein, Qt kann das nicht immer automatisch entscheiden. Zum einen gibt es gerade beim threading subtile Fehler, darum ist es so wichtig, dass ein Objekt erst zu einem anderen Thread gehoerig wird, bevor man sich mit Signalen damit verbindet. Und zum zweiten gibt es manchmal Probleme, bei denen man explizit will, das ein Signal erst verarbeitet ist, nachdem das aktuelle Event/Signal komplett durch ist. Das ist glaube ich in C++ relevanter, weil das keinen Garbage Collector hat, aber ist mir auch schon vorgekommen.

Was Punkt drei angeht - hmja. Ich denke es lohnt sich trotzdem, weil die Technik zu beherrschen wichtig ist.