Re: [wxVTK] wxAuiNotebook with wxVTK

[Mathieu M. <mat...@gm...>]

Hi there !

  Long time no activity on wxVTK, glad to see it is still active :)

  Kerry, I made some minor tweaks to the wxVTK class so that the
annoying debug leaks message does not appear anymore. You can now
build VTK with DEBUG_LEAKS=ON safely.

On Mon, Apr 7, 2008 at 11:33 PM, Sander Niemeijer <nie...@st...> wrote:
>  wxWidgets and VTK use different ways to delete objects. In this case
>  you want to delete it yourself the VTK way which is using '...-
>   >Delete()' and on the other hand a wx object is doing it the
>  wxWidgets way and thinks it can call 'delete ...'. This generates a
>  conflict. The delete will not decrese the VTK refcount and will result
>  in your VTK error, but you can't really prevent the call to delete
>  either (so doing your own Delete() will also give you trouble).
>
>  I had this problem as well and got it solved differently: I was
>  already using a derived class of wxVTKRenderWindowInteractor and for
>  that class I added the following part to the destructor (at the end):
>
>  ----
>      SetRenderWindow(NULL);
>      SetInteractorStyle(NULL);


That's always safe AFAIK. I can add those two lines to the destructor of wxVTK.

>      // Normally one has to remove a wxVTKRenderWindowInteractor
>  object using 'window->Delete()',
>      // but we also would like 'delete window' to work (which is
>  needed for e.g. Python wrapping)


Yeah, that's where you got me lost. ->Delete() from VTK world always
'delete this', so whatever wxWindows wants should be included in the
destructor (~wxVTK), but ->Delete is just a convention to call
~wxVTK() before doing some other VTK cleanups.

>      // This should be safe as long the reference count is 1 (i.e. no
>  other objects have a reference to this object)
>      // The problem is that we can't use Delete() or Unregister(NULL)
>  here, because that would recursively invoke the
>      // destructor. Therefore, we just explicitly decrease the
>  reference count by 1 if it was 1 (this way you will still
>      // get a warning from VTK if the reference count afterwards was
>  not 0).
>      if (GetReferenceCount() == 1)
>      {
>          SetReferenceCount(0);
>      }
>  ---
>
>  This is the safest solution to this issue that I know of.
>  Note that it also doesn't break a delete using the VTK-style Delete()
>  mechanism (since it won't do anything special if the reference count
>  is already 0, and the VTK Delete function will never call the
>  destructor if the refcount was still higher than that).
>
>  For your situation, you could probably adapt the
>  wxVTKRenderWindowInteractor.cpp itself (instead of creating a
>  subclass) and add the given routines to the (currently empty)
>  wxVTKRenderWindowInteractor destructor.
>
>  If this does indeed work, I think it might even be worth considering
>  to add this reference count trick to the wxVTKRenderWindowInteractor
>  destructor of the official wxVTKRenderWindowInteractor package. Mathieu?


I fixed the debug leaks thingy so that vtkDebugLeaks properly report
whether or not every VTK classes has been deleted. AFAIK everything
should be  fine now (ie all vtkObject have a ref count == 0 at
destruction time).
I know that on Win32 there are some issues, which I thought were fixed
in VTK 5.0, but this can be fixed as you mentionned by explicitely
setting the Renderwindow to NULL before destruction.

I'll add those two lines. And since I have some time on my hands, I'll
review the couple of patch that were send to the mailing list, but
from the top of my head they were already in CVS HEAD, simply not in
wxVTK 1.2

Thanks everybody for continued support and suggestions,
-- 
Mathieu