Yep correct
2016-05-06 1:01 GMT+02:00 Thiago Macieira :
> On quinta-feira, 5 de maio de 2016 22:21:08 PDT Filippo Cucchetto wrote:
> > void invokeDeleteLater(QObject* other) {
> > other->deleteLater();
> > emit aboutToBeDeleted(other)
> > }
>
> You want the emit before the deleteLater(),
On quinta-feira, 5 de maio de 2016 22:21:08 PDT Filippo Cucchetto wrote:
> void invokeDeleteLater(QObject* other) {
> other->deleteLater();
> emit aboutToBeDeleted(other)
> }
You want the emit before the deleteLater(), if the object can be in another
thread.
--
Thiago Macieira - thiago.
On quinta-feira, 5 de maio de 2016 19:09:59 PDT Sean Donnelly wrote:
> 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
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* oth
Looking at the implementation of deleteLater:
{
QCoreApplication::postEvent(this, new QDeferredDeleteEvent());
}
It seems to me you can achieve what you want without modifying the
implementation of deleteLater(), and instead making an event filter on
QCoreApplication for QDeferredDeleteEvent.
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 unt
