It depends on your use case but maybe you can simply create a QObject that
has the responsability of deleting your QObjects and emit a signal just
after calling deleteLater.
class MyDeleter : public QObject
{
...
signals:
void aboutToBeDelete(QObject*);
...
void invokeDeleteLater(QObject* other) {
other->deleteLater();
emit aboutToBeDeleted(other)
}
...
}
Depending on your architecture you can make it a singleton, global or
context variable.
After that you can replace everywhere:
objectManagedByCache->deleteLater()
with
myDeleter->invokeDeleteLater(objectManagedByCache).
You can also add this "invokeDeleteLater" directly to the class that
manages your cache.
2016-05-05 21:09 GMT+02:00 Sean Donnelly <[email protected]>:
> In our application we maintain a UI Inventory via a named object cache.
> When an object is destroyed we remove it from our cache and when the name
> is changed we also update our cache.
>
>
>
> However when an object is scheduled for deletion via
> QObject::deleteLater() the object remains in our cache until it’s actually
> deleted.
>
>
>
> I have two proposals:
>
>
>
> 1. Could deleteLater() send a signal so that we can update our
> cache immediately and not find that UI object which is about to be deleted.
>
> 2. Could deleteLater() set a property to know the object is in an
> “about to be deleted state”. That way our UI Inventory could be updated to
> ignore these objects.
>
>
>
> Thanks,
>
> Sean
>
>
>
> _______________________________________________
> Development mailing list
> [email protected]
> http://lists.qt-project.org/mailman/listinfo/development
>
>
--
Filippo Cucchetto
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
