From: Florian J. <flo...@we...> - 2011-10-14 20:39:20
|
Am 14.10.2011 19:23, schrieb Tim E. Real: >> you said you increased some delay. how was that delay implemented? >> >> was it a synchrounous sleep() or something similar? this for sure >> doesn't help, because it blocks the event loop. there's still no chance >> that the event loop deletes it first. >> > Correct. Exactly. Didn't help. > > >> the only way that "delay" would help, is to create an one-shot timer, >> EXIT the current function, (let the event loop really delete the >> objects,) and then wait for the timer to trigger the rest... but that's >> dirty AND complicated. >> >> a much easier workaround might be the following: >> simply make all toplevel windows become "deaf" when the close event >> arrives (given THAT it arrives), or the close() function gets called >> (overload it, first call deafen(); then call QMainWindow::close() ). >> "making it deaf" means: make it not react on anything any more. that is, >> disconnect it from any signals (or maybe only from the "dangerous" >> ones?). >> > Bravo, you hit the nail on the head. > > Relax, I've got a handle on the situation. Should have fix soon. > > Yes, this is a tricky fix for sure. > > It turns out when you close() a widget which has the WA_DeleteOnClose > attribute, Qt uses something called 'deferred delete', which is handled > differently than all other types of events. Control must be returned to > the event loop in order for the deletion to take place, later. > One cannot sit in a loop and call qApp::processEvents() waiting for some > sign that the object was deleted. It never happens ! > I tried that in MusE::clearSong, in the loop which closes the widgets > and checks for removal. It got stuck in the loop, waiting and waiting... > > Thus the only solution is to let Qt progress naturally, and while waiting > for things to happen, 'cut off' the widget from receiving the most > 'dangerous' signals causing the crash - in this case the songChanged > signal. In the case of PianoRoll, the ControlCanvas must also be cut off. > > Here's what I've done so far: > The slot named "MusE::toplevelDeleted()" was kind of mis-named > because it is not truly called when the object is deleted. > So I renamed it "MusE::toplevelDeleting()". > > Then I tapped into each of the TopWins' QObject::destroyed() signal > and connected them to a new method "MusE::toplevelDestroyed()". > It is this new method which actually removes the TopWin from the > toplevels list, instead of the old toplevelDeleted() doing it. > > At least this guarantees a more proper removal from the toplevel list, > only upon true, real deletion. > > Next it's just a matter of informing the widgets that close is pending, > and 'close their ears', be a 'zombie', and just wait for death by Qt. > > Trying to decide how to do that. Could use a signal which sets > a boolean which the songChanged() slots use as an 'ignore' flag. > Or, could nullify Canvas curPart member and use that as the flag. > don't! this doesn't work for all toplevel types! > Or, a couple of other options. Working it out... > > The ultimate solution is to 'bullet-proof' all the top wins and their > children from a nullified curPart. > rather use a bool deaf or so. > But this is a lot of work. Easier to just cut off the dangerous signals. > > Tim. > > >> dunno if that's possible. overloading connect to keep a list >> would maybe help, but that'll get more complicated than fixing the root >> cause ;) >> >> >> >> well, thinking about all this, there seems to be no easy solution ;) >> >> i'll try again: >> >> split the "loadSong" routines into "closeSong" and "loadSong". loadSong >> and closeSong should not depend on each other's stack variables. >> >> when you actually want to load a song, do one of the following: >> >> * call closeSong(); create an one-shot-timer which triggers >> loadSong() in 100ms. parameters (file name and stuff) must be >> stored somewhere. hackish. >> * call closeSong(), then emit a signal connected to loadSong(). >> MAYBE this works (because a queue is used, so TopLevel::closeEvent >> is first called, and THEN loadSong is called), maybe it shows the >> same problem (because emitting a signal only goes through a list >> of functions and calls them immediately and synchrounously). dunno. >> >> >> greetings >> flo >> >> >> > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > |