On Friday, 22 May 2015 16:36:11 CEST, Thomas Lübking wrote:
And this is why guarded pointers are shit - they do weird things ;-)
The object is still there, but it's only a qwidget - but we
access the dying object as if it still was a real webview.
It's actually not a QWidget anymore as ~QWidget has run already.
QWidget::~QWidget() however duplicates QObject's code which emits
destroyed(QObject*).
I wasn't successful in navigating the QPointer -> QWeakPointer -> QObject
maze -- I suspect that the destroyed(QObject*) signal is *not* what
invalidates QPointer instances.
Thanks for these directions, I think we're on a good track.
So we either would have to emit the destroyed signal explicitly
in our destructor
That sounds liek something *very* dangerous. For example
QObject::~QObject() takes care not to do it if it's (or was) a QWidget,
probably to prevent duplicate signals. I don't want to get trapped in
another tarpit :).
or connect the destroyed signal to a more robust hander
Yes, something along these lines looks like a good fix.
Feel free to test and commit and push, I won't have access to
my git ssh key today :-(
I'll be offline until late Sunday evening anyway, there's no hurry here. I
want to find out how QPointers are invalidated, too, because I always like
to understand the actual problem before we "fix" it improperly.
Notice that the m_lineEdit->clear(); is a slight behavioral
change and clears the search when opening another mail.
Sounds good; in an extra commit if possible please.
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
