>Hi folks,
>
>I'm trying to wrap my (extremely feeble) mind around an issue and I need some clarification. This concerns code written in VFP 8 and above, and the answer to this issue is -critical- to the timely completion of the app I'm currently working on.
>
>I have a "common code" Custom class which contains very frequently used code in its methods. This class is part of a class library which is accessible by either visual apps or "non-visual" components that may exist as VFP objects -or- COM objects. I use this common code class in MANY places throughout MANY apps, instantiating and releasing it as needed.
>
>As part of the app that I'm currently working on, I've also developed some data-driven classes that query some SQL Server metadata to mimic the appearance and functionality of the VFP Toolbox for use in several app forms.
>
>During this process, I've thought about placing some of the code that occurs frequently in these classes in the "common code" Custom class, storing the name and location of the class/classlib as properties of the toolbox classes (or in a local VFP config table, which already exists for each app), and then instantiating the common code in the Init() of the necessary toolbox pieces. Problem is, without that frequently used code, the toolbox pieces can't function and the Init() would have to abort if they weren't available. NONE of the other pieces of code in the common code class are required by any other classes to operate.
>
>I've also thought about making the common code class a required part of my "application object" when that instantiates.
>
>HERE'S THE QUESTION: By doing either of these things, does this action classify as "tight coupling" between the toolbox classes and the common code class? If so, is that acceptable for this process, and which way should I do it? If not, WHY?? And, if it's not, what are some of my alternatives and what are the benefits/drawbacks to those alternatives?
>
>All your thoughts and explanations are appreciated...

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