[vtkusers] Serious(?) flaws in vtk code

Mathieu Malaterre mathieu.malaterre at kitware.com
Wed Mar 10 16:50:07 EST 2004 

Well it is more than rumor, or rumor get paid ! They have actually 
invest in wxwidget, just like microsoft pay for the change of their name.

http://www.wxwidgets.org/borland01.htm

Mathieu

Luca Picello wrote:
> Well... I think BCB6 will survive for a long time because the new 
> BuilderX is a completely different product and it is not mature yet.
> And probably it will be not for a long time: there are rumors that 
> Borland will change again the BuilderX platform to include wxwindows ( 
> http://www.wxwindows.org ) libraries.
> So stay tuned and help all of us that use BCB all day long to fix and 
> upgrade it more because it is powerful but not perfect, yet!
> I hope to have time asap to fix the "ProjectDemo" myself but I am new to 
> VTK and I do not know how to do it yet.
> Right now the problem disappear even if you compile your project and 
> package using runtime dll (Options->Linker->Use dynamic RTL).
> Is it a real problem to include borland dlls till this problem is solved?
> 
> Luca
> 
> PS: if you believe microsoft .net will be the future... well.. it is a 
> completely different product from previous visual studio and it is at 
> the same point of builderx.
> Use both of them at your risk :-)
> Take care
> 
> 
> 
> John Biddiscombe wrote:
> 
>>VTK\Examples\GUI\Win32\vtkBorland\ProjectDemo
>>
>>it's the original Borland demo, which has never been attended to. Please fix
>>it if you have time. Mind you, now that Borland are dumping BCB, it's worth
>>discouraging people from adopting it.
>>
>>JB
>>
>>----- Original Message ----- 
>>From: "William A. Hoffman" <billlist at nycap.rr.com>
>>To: "Xianjin Yang" <Yang at AGIUSA.COM>; <vtkusers at vtk.org>
>>Cc: "Per Dalgas Jakobsen" <pdj at maridan.dk>
>>Sent: Wednesday, March 10, 2004 2:13 PM
>>Subject: RE: [vtkusers] Serious(?) flaws in vtk code
>>
>>
>>  
>>
>>>Where is Project_vtkDemo?  Can it be fixed so other people
>>>do not run into this problem?
>>>
>>>-Bill
>>>
>>>
>>>At 12:32 PM 3/9/2004, Xianjin Yang wrote:
>>>
>>>    
>>>
>>>>Dear all,
>>>>
>>>>I have been using BCB6 + VTK 4.2 and had similar problems before.
>>>>To solve Access violation problem related to DummyCritSect.Lock() in the
>>>>      
>>>>
>>destructor of vtkPolyData (~vtkPolyData), I did these in the
>>Project_vtkDemo:
>>  
>>
>>>>1) Remove everything in the FormDestroy event handler.
>>>>2) Add this FormClose event handler. All problems should be gone!!
>>>>
>>>>void __fastcall TVTK_Form::FormClose(TObject *Sender, TCloseAction
>>>>      
>>>>
>>&Action)
>>  
>>
>>>>{
>>>> if (shrink) shrink->Delete();
>>>> vtkTimerLog::DeallocateTimerLog();
>>>> vtkWindow1->GetRenderer()->RemoveAllProps();
>>>> // VTK_Form->Release();
>>>> // Application->Terminate();
>>>>}
>>>>I am not sure if the last two lines of code are required in BCB6.
>>>>
>>>>vtkTimerLog::DeallocateTimerLog() is a fix discussed here:
>>>>      
>>>>
>>><http://public.kitware.com/pipermail/vtkusers/2003-August/019522.html>http:
>>>    
>>>
>>//public.kitware.com/pipermail/vtkusers/2003-August/019522.html
>>  
>>
>>>>Xianjin Yang, Ph.D.
>>>>
>>>>
>>>>
>>>>-----Original Message----- 
>>>>From: William A. Hoffman
>>>>      
>>>>
>>[<mailto:billlist at nycap.rr.com>mailto:billlist at nycap.rr.com]
>>  
>>
>>>>Sent: Tuesday, March 09, 2004 10:18 AM
>>>>To: Per Dalgas Jakobsen; vtkusers at vtk.org
>>>>Subject: Re: [vtkusers] Serious(?) flaws in vtk code
>>>>
>>>>I have not looked at the BCB Windows code, however,
>>>>it seems that you might be able to move the creation/destruction
>>>>of the vtk objects to a different spot.   There must be some method
>>>>that is called to initialize the BCB objects, and another one
>>>>to destroy them.   You could go to some sort of lazy create if
>>>>there is no such method.   Basically, the first time the vtk object
>>>>is used, then create the vtk object.  Then when your window gets the
>>>>      
>>>>
>>close event, destroy the vtk object, don't just create and destroy the vtk
>>objects in the constructor/destructor of the BCB object. All vtk objects
>>should be created after main, and deleted before the end of main, and you
>>should have no problem.
>>  
>>
>>>>-Bill
>>>>
>>>>At 04:19 AM 3/9/2004, Per Dalgas Jakobsen wrote:
>>>>      
>>>>
>>>>>Hi all,
>>>>>
>>>>>I believe I have found some flaws in the vtk code.
>>>>>I think most vtk users are not affected, but us poor souls that are
>>>>>forced to use Borland C++ Builder (BCB) are affected.
>>>>>        
>>>>>
>>>>>The problem reveals itself the following way (in my case at least):
>>>>>Access violation in the destructor of vtkPolyData (~vtkPolyData) - The
>>>>>DummyCritSect.Lock() call fails.
>>>>>
>>>>>The cause is that DummyCritSect, in certain cases, has already been
>>>>>destroyed. In other words: ~vtkPolyData is calling a method in an
>>>>>object that is no longer in existence.
>>>>>
>>>>>Explanation:
>>>>>DummyCritSect is a "nonlocal" object which is created before main() is
>>>>>executed, and destroyed after main() has returned. This is actually
>>>>>what is intended, and quite nice, except when used from within (but not
>>>>>exclusively) BCB...
>>>>>
>>>>>The problem is that the Visual Component Library (VCL), which is the
>>>>>foundation of BCB, also seems to be created from a "nonlocal" object.
>>>>>This means that BCB Windows and DummyCritSect are created at the same
>>>>>point, and destroyed at the same point, but the sequence is undefined.
>>>>>
>>>>>According to "The C++ Programming Language" by Bjarne Stroustrup:
>>>>>------- 
>>>>>Section 10.4.9 Nonlocal store:
>>>>>
>>>>>1) "A variable defined outside any function (that is, global,
>>>>>namespace, and class static variables; §C.9) is initialized
>>>>>(constructed) before main() is invoked, and any such variable that has
>>>>>been constructed will have its destructor invoked after exit from
>>>>>main()."
>>>>>
>>>>>2) "No implementation-independent guarantees are made about the order
>>>>>of construction of nonlocal objects in different compilation units."
>>>>>
>>>>>3) "The order of destruction is similarly implementation-dependent."
>>>>>------- 
>>>>>
>>>>>This means that IF vtk is accessed from a "nonlocal" object, it is
>>>>>implementation-dependent wether it works or not. In case of BCB, it
>>>>>doesn't :-(
>>>>>
>>>>>As long as you are not making components containing vtk-code in BCB, it
>>>>>is possible to make workarounds, but it seems to be impossible to get
>>>>>component-wrapped vtk-code to work correctly.
>>>>>
>>>>>
>>>>>How do we get around this problem?
>>>>>I don't think that we should "#ifdef __BORLANDC__" our way out of the
>>>>>BCB problem, this will leave the code flawed for projects using
>>>>>nonlocal objects. Any thoughts?
>>>>>
>>>>>
>>>>>Best regards
>>>>>Per
>>>>>
>>>>>        
>>>>>
>>>_______________________________________________
>>>This is the private VTK discussion list.
>>>Please keep messages on-topic. Check the FAQ at:
>>>    
>>>
>><http://public.kitware.com/cgi-bin/vtkfaq>
>>  
>>
>>>Follow this link to subscribe/unsubscribe:
>>>http://www.vtk.org/mailman/listinfo/vtkusers
>>>    
>>>
>>
>>_______________________________________________
>>This is the private VTK discussion list. 
>>Please keep messages on-topic. Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
>>Follow this link to subscribe/unsubscribe:
>>http://www.vtk.org/mailman/listinfo/vtkusers
>>.
>>
>>  
>>

More information about the vtkusers mailing list