[vtkusers] Access Violations in wxVTKRenderWindow Example

Charl P. Botha c.p.botha at its.tudelft.nl
Mon Jan 20 18:12:12 EST 2003


Howdy Prabhu,

On Mon, Jan 20, 2003 at 11:14:07PM +0530, Prabhu Ramachandran wrote:
> >>>>> "CPB" == Charl P Botha <c.p.botha at its.tudelft.nl> writes:
> 
>     CPB> The solution is something like this when you Destroy() a
>     CPB> frame containing a wxVTKRenderWindowInteractor:
> 
> [snip]
> 
>     CPB> The self._rwi is a wxVTKRenderWindowInteractor and the
>     CPB> self._view_frame is a containing frame.  If you _don't_ do it
>     CPB> this way and Destroy() the containing frame, your application
>     CPB> will crash with a BadWindow error (or similar) as the
>     CPB> RenderWindow destructor assumes that the window it's
>     CPB> rendering to still exists.
> 
>     CPB> I don't know whether one should modify all the RenderWindows
>     CPB> to be a bit more intelligent about this.  Your thoughts?
> 
> Looks like a good idea.  It would be nice if we could make the
> interactor more intelligent so that the user does not have to worry
> about this.

I've worked on this problem some more.  My solution of adding an event
handler (that calls Destroy() on the containing frame) to the DeleteEvent of
the RenderWindow is not terribly robust, especially with Python's garbage
collection.  The solution I'm using now is to call WindowRemap() which
causes the RenderWindow to create temporarily a new window of its own,
detaching from the wxWindows part so that it can safely be destroyed.

There doesn't seem to be a clean solution that can be implemented in the
destructor of the RenderWindow: calling glxDestroyContext() does require a
valid drawable.  I would say that the WindowRemap(), or something similar,
is probably a good way.

> Charl, if you don't receive this mail directly and only receive a copy
> from the list, please let me know.  I'd like to take the discussion
> off the list but if that is not possible we have a small problem and I
> have to work around it.

I did not receive the mail directly, I'm afraid.  We could continue this on
vtk-devel?

Thanks,
Charl

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/



More information about the vtkusers mailing list