Hi Al,

Your code is almost -exactly- what I do in the Init() method (my property is called ioCommon).

Sure, it's --possible-- to do this in the Load() method. However, I don't understand what benefit(s) might occur from this change -- and I seem to remember having difficulty successfully altering object properties before the Init() of that object begins executing. Maybe that's been fixed, but still...

Also, wouldn't it cause an issue if the Init() fails, since the oToolbox object doesn't actually exist until the Init() finishes? (BTW, in the proposed oToolbox.Init(), I wouldn't instantiate oToolbox.ioCommon unless the default Init() behavior completed successfully.)

I suppose I could augment the Unload() to be sure that the ioCommon object reference has been released -- but then, does the Unload() always fire if the Init() fails? Sounds a bit like a deeper rat's nest to me...



>Before delving too deeply into architecture issues, would it be possible to instantiate oCommon in your toolbox's .Load rather than .Init? I don't know how you're doing it now - maybe creating an .oCommon custom property of your Toolbox e.g.

oToolBox.oCommon = CREATEOBJECT( ... )