[vtkusers] wxVTKRenderWindowInteractor + vtkImageViewer2

[Charl P. Botha]

On Wed, 2003-09-03 at 19:09, Mathieu Malaterre wrote:
> Charl P. Botha wrote:
> > On Wed, 2003-09-03 at 14:43, Mathieu Malaterre wrote:
> > 
> >>	To sum up quickly the problem, wxWindows need a special vtkRenderWindow 
> >>which is build within wxVTKRWI. Whereas vtkImageViewer2 built its own 
> >>too and override the one previously build. I first thought of adding a 
> >>method: vtkImageViewer2::SetWindowInfo, but I found it ugly for 
> >>vtk-users -furthermore it would introduce differences between a standart 
> >>vtkRWI-.
> > 
> > 
> > Is there a reason why you had to move the SetWindowInfo() code out of
> > the constructor to the OnPaint()?
> 
> 	If you look at vtkImageViewer2::SetupInteractor, you'll see that the 
> renderwindow is set in this method. So I had to find a method called
> after that -and still invisible for vtk-users-.
> 	Furthermore, for my c++ class I had so many problems if I set the 
> window ID too early that's why I decided to set it up only on the very 
> last minute (=during the OnPaint call).
> 
> But as I said, I am open to any other suggestion, the conditions are:
> 
> * There shouldn't be any explicit call to SetWindowInfo outside of wxVTKRWI
> 
> * Allow other VTK filters to set their own vtkRenderWindow
> 
> I also thought of adding a 'def SetRenderWindow (...):' but we have to
> be very carefull not to collide with the '__getattr__(self, attr)' ...
> 
> > 
> >>	Therefore I change the wxVTKRWI.py code so that it uses the 
> >>vtkRenderWindow from the vtkGenericRWI, even if it has been set by 
> >>another filter, for example vtkImageViewer2.
> > 
> > 
> > Okay, this sounds okay.  The essential change you have made is that
> > wxVTKRWI doesn't keep its own binding to the RenderWindow, right?
> 
> exactly.

Prabhu, I'd like to apply this patch of Mathieu's.  Do you have any
thoughts on the matter?

Thanks,
Charl

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