[vtkusers] Bug in vtkDataArray.cxx; was: Bug in vtkWin32OpenGLRenderWindow when using own Interactor and windowhandle

[Sander Niemeijer]

Roland,

This MFCHandledWindow parameter makes things indeed more complicated. 
But regretfully your suggestion would not work. If MFCHandledWindow 
would be true, than the ren->SetRenderWindow(NULL) in the clean routine 
still wouldn't be called, which was my initial concern.

I also start to believe that in order to solve both your and my problem 
some bigger changes need to take place in vtkWin32OpenGLRenderWindow. 
Maybe the cleanup of VTK specific stuff in Clean() needs to be seperated 
from the win32 stuff and moved to another method in order to properly 
deal with the conditional cleanup problem.

One thing I was also wondering about is the release of the device 
context. I guess this shouldn't be released if MFCHandledWindow is set 
to true, but what should happen if OwnWindow is false?

Anyway, I think that it would be wise that the person who is going to do 
the bugfixing tries to get things straight in the 
vtkWin32OpenGLRenderWindow class when it comes to initialization and 
cleanup of Win32 windows, DCs, VTK object references, etc. and not just 
focusses on the two problems we are having. I'm not sure, but our 
problems suggest that there might be more broken with regard to proper 
initialization/cleanup than we currently now.

Regards,
Sander Niemeijer

On woensdag, maart 20, 2002, at 07:57 , Roland Schwarz wrote:

> This applies to:
> vtkWin32OpenGLRenderWindow.cxx Rev. 1.81
> ===================================
>
>>>> By the way, I was wondering... Is this list the appropriate place to
>>>> post bugreports?
>>>> I have posted another bugreport to this list a month ago about a bug 
>>>> in
>>>> vtkWin32OpenGLRenderWindow but I still haven't received any response 
>>>> on
>>>> that e-mail.
>
> That is very interesting: I messed around with the 'Win32SampleMFC' 
> example
> for a while and came to a different solution:
> I explicitely removed all actors from the renderer on window destruction
> (which does a ReleaseGraphicsResources in the right place).
>
> Then I explicitely called this->RenderWindow->Clean(), before I noticed 
> that
> calling Clean allone is sufficient.
>
> I also do not see a reason why the call to Clean should'nt be in the
> destructor unconditionally. It must be called anyway.
> One exception of course would be when the MFChandledWindow flag is 
> true, in
> which case the embedding window has more responsibility for the
> RenderWindow.
>
> Restating your post I would recommend the following addition:
>
> if (this->WindowId && !this->MFChandledWindow) /* MFC flag added to
> suggested bug fix from Sander Niemeijer */
> {
> this->Clean();
> if (this->OwnWindow)
> {
> ReleaseDC(this->WindowId, this->DeviceContext);
> // can't set WindowId=NULL, needed for DestroyWindow
> this->DeviceContext = NULL;
>
> // clear the extra data before calling destroy
> SetWindowLong(this->WindowId,4,(LONG)0);
> DestroyWindow(this->WindowId);
> }
> }
>
> (Hopefully someone of the developers will have a look on our postings.)
>
> BTW.: This also removes the crash of the Win32SampleMFC example program.
>
> Roland
>
>
>
>
>