From: Milan B. <mil...@gm...> - 2008-04-25 06:52:27
|
On Thu, Apr 24, 2008 at 10:54 PM, Michael Hieke <mg...@gm...> wrote: > The current SVN version does not work at all on Windows; if I open the > property page for a database and then disconnect the database I get > assertions, and in release mode the code will probably crash. The > problem is the following chain of events: > > - database gets disconnected > -> calls notifyObservers(), which loops with a forward iterator through > its observersM list > -> MIPF::update() finds the database disconnected and calls > removePanel(this) on the main frame I assume you mean MIPP, not MIPF here. Of course, MIPP code should be extracted and moved to a separate file. I'll do that as soon as I complete the new one-MIPF-per-database concept and we try it out and decide it is good. > -> the MIPF and its notebook page are removed and destroyed, which > removes the MIPF from the observersM list in the database > -> now an invalid iterator is being incremented > > There may be some way around all of this Looks like the current way destruction is handled is not really good. This is not the only piece of code where removeSubject is overriden, so maybe it would be a better idea to fix the Subject code to prevent this kind of problems. Please try the code I have just committed. If that doesn't work (although it should), we can always create a copy of observersM and iterate over that. > few minutes I looked at the code. And since the old code (which called > only MIPF::Close()) worked fine I feel that maybe the general idea is > flawed somehow. When Close() is used, wxWidgets does a delayed destruction, so observer doesn't remove itself right away, but after all wx events are processed. > I especially dislike that MetadataItemPropertiesPanel > overrides removeSubject(), that seems to be the wrong way of getting rid > of the wxAUI pane. All the observers that need to 'close' themselves use the same approach. I guess we were lucky none of them destroyed itself in that handler. > Does this work for you on Linux? Yes. > Maybe because wxGTK does a lot of > stuff in idle time, so that the iteration over the observers isn't > disturbed? Seems like window deletion is not done at the same time, so it survives. -- Milan Babuskov http://www.flamerobin.org |