On Wednesday, 18 December 2013 11:59:15 CEST, Ola Røer Thorsen wrote: > However I get problems when I delete objects from the list model. The > delegates are deleted later than the actual objects, so I get warnings from > QML on the console (saying myObject is null). These seem harmless enough, > but I would like to avoid having any warnings at all.
When working with the QAbstractItemModel, items can only be deleted via resetting the model, or when removing rows/columns. The row/column removal shall happen in three phases: 1) call beginRemoveRows 2) remove the internal representation, freeing the MyObject instances 3) call endRemoveRows I will argue that if a delegate is alive after the beginRemoveRows finished, then the QML view is broken. The view shall react to rowsAboutToBeRemoved and kill any delegates in response to that signal. However, you absolutely must not free your internal representation prior to calling beginRemoveRows. Are you sure that this is not the case? > Item { > id: theDelegate > property string someValue: myObject ? myObject.someObjectValue : "" > } > > but this is just ugly. Something is apparently picking up some signal which causes the delegate to notice that the value of "myObject" has changed. What signal is it? Are the delegates alive even after rowsAboutToBeRmoved is emitted? > The alternative is to create roles for every property in MyObject, and > connect signals for every one of them so the model updates when one of the > properties changes. Perfectly doable of course, but it has to be kept > up-to-date with the properties in MyObject, and feels like duplicating a > lot of code. It's interesting that you've solved the problem of too many roles by using a QObject instance within the model itself. I wonder whether this is actually a good path -- QObjects are rather heavyweight, so it is a question whether you gain anything by trading the disadvantage of "got to call the model's data() too many times, once for each role" by another problem, "got to manage expensive QObjects instead of some liteweight internal nodes". Perhaps it fits the rest of the code and using QObjects "inside" the model makes sense. However, if that was not the case, simply emitting dataChanged() when any "property" changes migth be even easier (and would elliminate the need to use properties and separate signals in the first place). With kind regards, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest