Philipp Lohmann - Sun Germany wrote: > Frank Schönheit - Sun Microsystems Germany wrote: >> No. The MyTabPage implemented a handler for the GetFocus event of one of >> its children. Please examine the original example more carefully ;) > > Point taken. > >>> The other case you mention has nothing to do with >>> derivatives of Window at all; of course you have to be careful that a >>> member does not access the already partially destroyed parent. >> >> That's the point: VCL does this. When a window is destroyed, it's child >> windows (held as members) are destroyed, too. Now if one of those >> members has the focus, VCL moves the focus to another suitable control - >> either the being-destroyed window itself, or to a sibling of the member >> window. In both cases, VCL calls into a partially destroyed instance. > > I just tried to say that this has nothing to do with focus handling in > particular. You always have to handle such cases, this can happen as > soon as you implement a virtual method (or a callback for that matter).
That is as correct as useless. :-) Of course you can simulate the same situation with other classes, the pattern indeed is not unique to VCL, but at least until now no other case is known where it can be found. I don't see value in using abstract terms for a bug description if a concrete and very expressive example exists. Moreover, explaining the way how the bug is triggered and what the trigger (not the root cause!) is is helpful because it might lead to ideas for a solution even if you can't fix the root cause. If you remove the trigger, the bug won't happen. I don't know if this is possible here but IMHO thinking about it is worth the effort (see below). IMHO the trigger is the focus change, the root cause of cause is the overall architecture that spreads object dependencies over several libraries, lacks refcounting, executes too much and too complex code in the dtor etc. In concrete terms: if the control had a reference to the tabpage instead of a pointer it can't call into a partially destructed page. Of course then windows always must be destroyed by a dispose or close call. I know that there still are some pitfalls but it's easier to see and avoid them. As we can't work on this we have to search and apply a fix for the particular situation. The only fix we have found until now is to use an explicit call of a method of the edit control(s) from inside the dtor of the TabPage that prevents the edit control(s) from calling back. This can be removing the link, setting a flag at the derived control (or setting the pPage pointer to zero, a "handcrafted" weak pointer) that is checked before the page is called back or hiding the controls explicitly so that your suggestion with "IsVisible()" can work. If anybody has a better idea that can prevent the occurence of our bug by fixing something in VCL please let us know. This would save us the investigation and fixing of all the other cases shown by Carsten. Please consider that Carsten only showed us the places where the link is used, we still have to look for cases where the overwriting of GetFocus() is used, something that will be time consuming. It would be nice to save all this time for other tasks. Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
