(No need to Cc me, I read the list.) > The delegate is alive for a short period after this, it seems. I guess > maybe just another event loop cycle? I didn't investigate it further yet > though.
Interesting. If that is indeed the case, perhaps you could use distinct delegates based on the value of myObject, but I suspect one cannot do this after the delegate was already instantiated. Anyway, what is rather interesting is to find out how exactly the delegate learns that the actual value of "myObject" has changed. Perhaps it does not actually learns this via the usual MVC channels and this only happens by chance due to the fact that you are using property bindings on top of the returned object. I.e. the delegate previously set up a binding to a property of myObject, the referenced QObject ceases to exist, the binding gets invalidated (?) and the delegate reacts to that by re-evaluating the expression, only to find out that the myObject is now null. What happens if you change the deleteLater() to an immediate delete (and move it between the beginRemoveRows and endRemoveRows)? Are you deleting your items in the middle of the list, or always at the end? Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
