| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 3 | |
Hi, so the manual says DeferredDeletion is deprecated. What's the replacement? Unfortunatly there is no other way then proccessEvents to make QxmlStreamReader actually recover recursion from network data. (function pointers maybe, but....). Maybe i'm blind. Other people would use a thread i bet >_< Everything works great, except a gui application doesn't exit if you close the mainwindow. naturally, since the mainwindow won't get deleted at all. unfortunatly if my reader is part of a mainwindow, it won't get deleted, so no recursion exit, so no application closing. bad. DeferredDeletion does fix that. But i don't want to put new technology on deprecated API. best regards Arvid Ephraim Picciani -- [ signature omitted ]
Arvid Ephraim Picciani wrote:
> Hi,
> so the manual says DeferredDeletion is deprecated. What's the replacement?
QApplication::sendPostedEvents(0, QEvent::DeferredDelete); // all objects
QApplication::sendPostedEvents(object, QEvent::DeferredDelete); // one object
The QObject::deleteLater() rules still apply though. An object will not be
deleted if the event loop recurses after calling deleteLater() on it. The
above only works if deleteLater() was called in the same frame, i.e.:
object->deleteLater();
// stuff, but no {QDialog,QMenu,QEventLoop)::exec() calls
QApplication::sendPostedEvents(object, QEvent::DeferredDelete);
> Unfortunatly there is no other way then proccessEvents to make
> QxmlStreamReader actually recover recursion from network data. (function
> pointers maybe, but....). Maybe i'm blind. Other people would use a thread i
> bet >_<
> Everything works great, except a gui application doesn't exit if you close the
> mainwindow. naturally, since the mainwindow won't get deleted at all.
> unfortunatly if my reader is part of a mainwindow, it won't get deleted, so
> no recursion exit, so no application closing. bad. DeferredDeletion does fix
> that. But i don't want to put new technology on deprecated API.
--
[ signature omitted ]
On Friday 14 March 2008 15:40:48 Bradley T. Hughes wrote: > QApplication::sendPostedEvents(0, QEvent::DeferredDelete); // all objects > QApplication::sendPostedEvents(object, QEvent::DeferredDelete); // one > object ah! thank you. > The QObject::deleteLater() rules still apply though. An object will not be > deleted if the event loop recurses after calling deleteLater() on it. The > above only works if deleteLater() was called in the same frame, i.e.: yeah, that's fine. -- [ signature omitted ]
Bradley T. Hughes wrote: > The QObject::deleteLater() rules still apply though. In Qt3 deleteLater in combination with modal message boxes ( mostly displaying errors ) was one of standard problems, that lead to segfaults. So one of the first things I always did, was to reimplement QApplication::notify to block all deferred deletes in recursive event loops. I always thought, that this type of problem is so common, that something should be done in Qt itsself. Did the situation change with Qt4 ? Uwe -- [ signature omitted ]
On Friday 14 March 2008 15:32:48 Arvid Ephraim Picciani wrote: > Hi, > so the manual says DeferredDeletion is deprecated. What's the replacement? > Unfortunatly there is no other way then proccessEvents to make > QxmlStreamReader actually recover recursion from network data. (function > pointers maybe, but....). Maybe i'm blind. Other people would use a thread > i bet >_< > Everything works great, except a gui application doesn't exit if you close > the mainwindow. naturally, since the mainwindow won't get deleted at all. > unfortunatly if my reader is part of a mainwindow, it won't get deleted, so > no recursion exit, so no application closing. bad. DeferredDeletion does > fix that. But i don't want to put new technology on deprecated API. There are three threads on the subject on qt4-preview-feedback. Basically we've finally got right what Deferred deletion should have been for Qt 4.0: objects get deleted when (and only when) you go back to the event loop. If you start a nested event loop, they don't go away. processEvents() is a nested event loop. So it doesn't delete anything. Now, I don't understand the issue: what's wrong with QXmlStreamReader? -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On Friday 14 March 2008 15:44:32 Thiago Macieira wrote:
> Now, I don't understand the issue: what's wrong with QXmlStreamReader?
there is no way to recover the current recursion when you get an EOF.
well ... example:
<a>
<b>
<c/>
</b>
</a>
transmited over network.
<a>
<b>
<EOF
so, now readNext returns false.
let's say you actually use stack recursion (becouse it is way more convinient
then state engines, and becouse the examplesy tell you to.)
you have a function readA() readB() and readC()
the eof happens while you do readNext() in readB(), so you have to exit that
function. you can connect readyRead, but connect to what? there is no way
you can go back to readB().
Well my solution was to start a nested loop in readB(), so now you can go do
other stuff while there is no readyRead(), then when readyRead() is emited,
it sets a flag and your stack falls back to the mainloop.
Works nicely. with some trickery it now even works when deleting the object
while in recursion ;D
The only issue is that the nested loop prevents the mainwindow from beeing
deleted. and the recursion only stops manually or by deleting the reader.
--
[ signature omitted ]