> I think I understood that after the second read. Ensuring that your code does not trigger the instantiation of objects that in turn instantiate others?

The most important takeaway is that code in ReadProperties and WriteProperties events of a usercontrol are *executed* during compilation. The IDE prepares a temporary environment (not everything is as normal) and the interpreter runs actual code during compilation of forms which host usercontrols.

This means you cannot have a VB6 compiler clone (hint: TB) without first having an interpreter which can run code in Read/WriteProperties if you have to be 100% VB6 compatible. As a consequence it is your own resposibility to not leak resources in these events or stunt the compiler and make your project uncompilable. Instantiating global objects is one way to leak memory esp. if there are circular references involved.

The global objects are tricky as you never deallocate these as there is usually no harm these leaking when process terminates. It is during compilation that not leaking global objects becomes important as temporary environment is setup and teared-down on multiple occasions so you might leak multiple copies of such global objects.

cheers,
</wqw>