[vtkusers] Serious(?) flaws in vtk code

[Per Dalgas Jakobsen]

Hi all,

Again, thanks for your feedback.

I have been ping-pong'ing with a borland newsgroup to find a better workaround. I found a workaround, wether it's better or worse, decide for yourselves, but it seems to do the trick for me :-)

Instead of doing all these specialized things in every project in which I use VTK, I have found a solution that can be included into the vtkBorlandRenderWindow source, without requiring any changes to the normal way of using VCL. That is: the users of the VCL-wrapped VTK components does not have to make any special magic to get it to work.
The fix is rather dirty, but again, it seems to work.


vtkBorlandRenderWindow.cpp:
--- Original ---
namespace Vtkborlandrenderwindow
{
  void __fastcall PACKAGE Register()
    {
    TComponentClass classes[1] = {__classid(TvtkBorlandRenderWindow)};
    RegisterComponents("Samples", classes, 0);
    }
}

--- New ---

+ static bool InDesigner = false;
+
+ void vtkWorkAround(void)
+ {
+     if (!InDesigner) {
+         ShowMessage("Workaround");
+         delete Application;
+         Application = new TApplication(NULL);
+     }
+ }
+
+
+ void InstallvtkWorkAround(void)
+ {
+     atexit(vtkWorkAround);
+ }
+ #pragma startup InstallvtkWorkAround
+
+
namespace Vtkborlandrenderwindow
{
  void __fastcall PACKAGE Register()
    {
    TComponentClass classes[1] = {__classid(TvtkBorlandRenderWindow)};
    RegisterComponents("Samples", classes, 0);
+     InDesigner = true;
    }
}
------
Remember to add the define "STRICT" to the ... defines. To get VTK to compile.


A more thorough explanation on the workings of this workaround can be found at the borland newsgroup: news:borland.public.cppbuilder.vcl.components.writing in the thread with subject: "Designtime or runtime" in my third (and so far last) post.

The relevant quote from that post:
---
The problem relates to a nonlocal object, on which the dynamically
allocated VTK objects depend during destruction. Unfortunately this nonlocal object is destroyed BEFORE the VCL, and thereby the dynamic VTK objects => Access violation.

To workaround this problem, I found out that I could destroy the Application variable myself in the project source, just before the return from WinMain().
To keep the BCB runtime from crashing when it tries to destroy the
Application variable, it is recreated (without forms).
In that way I ensure that the VCL-objects are destroyed before nonlocal objects are, keeping the nonlocal object valid during VCL/VTK destruction.

To wrap things nicely to the users of these components, I thought I would make this Application destroy/recreate trick from within the library.
Unfortunately the #pragma exit functions are executed AFTER the destruction of nonlocal objects. Luckily functions registered with the standard C function atexit() are called BEFORE the destruction of nonlocal objects.
The solution then were to install an atexit-function, in the librarys startup code, which simply made the Application destroy/recreate trick.

However, while within the designer, things works as (I think) they should.
The nonlocal object are destroyed after the VCL/VTK objects. In addition the Application destroy/recreate trick made havoc.

So what I have tried now is to install this atexit() handler, to make the Application destroy/recreate trick IF not within the designer (or in context of BCB).

I have now implemented the workaround, and everything seems to work
perfectly.
---

Hope you guys find some of this useful.


> 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.

Even if they had continued BCB, I would still discourage people from using it ;-)


Best regards
Per


---
IMPORTANT
The information contained in this e-mail is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by e-mail or telephone.
Thank you in advance.
---