>
Alfred N. Van Hoek, Ph.D. wrote:
>Since you have a destructor, you can call it also
>by yourself in the constructor, or other event.
I believe that this won't work because the destructor
is just a subroutine that is there to do some cleanup.
However, the destructor routine I can implement in the
plugin has no control about the allocation of the
object. That is done at a higher level, in the runtime
system of RB.
Let me explain to you how it currently works in RB
(or, how I understand it works):
First, the RB app executes this code:
x = new MyClass
This invokes some code in RB's runtime lib that
does:
- allocate some memory for the object, including
the amount of bytes the plugin wants for itself.
- call the plugin's constructor method
- return the address of the obj's memory to the
RB caller, ...
... and that returned obj address then gets assigned
to "x".
Now, how could I intercept this process when the
constructor code of my plugin decides that the
obj must not be returned but that it must be disposed
of and that nil must be returned instead?
Calling the plugin's destructor code will not do anything,
because that has zero effect on the above code that
creates the obj and then, after calling the plugin
constructor function, returns the obj's address.
You see what I mean?
Thomas
--
Thomas Tempelmann, Macintosh software developer
<<A HREF="http://www.tempel.org/";>http://www.tempel.org/</A>>
|