🚀 go-pugleaf

This talk about destroying zones to get rid of objects, reminds me of a  
strange bug I have encountered recently:

I have a program, which dynamically loads modules, with their own nib and  
objects.  I created a zone for the File's owner object, which eventually  
loaded the nib file into that zone.  Each time I loaded a new module, I  
unloaded the previous module and destroyed its zone to get rid of  
everything.  In addition to that, I did not use the modules' window, but  
stealed its view hierarchy which I then added as a content view of the  
main program window.  This worked fine, until I put a ColorWell in one of  
my modules.  What happened then, was that the ColorWell behaved correctly  
the first time the module was loaded, but if I loaded it later and  
activated the Well, the program crashed.
The only way I could make it work was to put one ColorWell in the main  
window, such that that class would always be loaded.  I don't know the  
real reason for this bug, but I guess that once you pop up a color panel  
using the ColorWell, the panel must somehow remember who popped him up, so  
if you then destroy the module and the ColorWell with it, the next time  
you try to popup the Color Panel, it tries to send a message to its  
previous Well.  Does anybody have clues to this problem ?  Are there other  
objects with the same behaviour ?  What is the criterion which determines  
whether an object will not support a zone destroy ?

-Kjartan

PS.:  How does one build a shared library with some custom classes, say  
for example a library corresponding to a user defined palette ?
--
Kjartan Pierre Emilsson			e-mail: kjartan@ecu.unice.fr
Non-Linear Institute of Nice		tel.: 93 52 98 36
Universite de Nice - Sophia Antipolis	fax: 93 52 98 48
Parc Valrose
Nice, FRANCE