>>>>Within Project1, execute the command:
>>>>
>>>>SET PATH TO "..\aControls\,..\cControls"
>>>>
>>>>Fox will then look for a File in Project1, if it cannot find it, it will look for it in aControls, if it cannot find it here as well it will look for it in cControls.
>>>>
>>>>Notes:
>>>>(1) I assume your working folder is Project1.
>>>>(2) aControls can be a sub-class of cControls if necessary
>>>
>>>The way I understood the question and I do not know a simple answer to it is to have a composite class (container based) with some controls (textboxes, labels, etc.) The class should be generic enough to be reused in multiple projects yet have custom look depending on the project (e.g. different label fonts, textbox fonts, etc.).
>>
>>I would not try to subclass everything in sight, i.e. making a separate class for every textbox font looks overzealous. Imho, one custom class for each baseclass is a requirement (e.g. mytextbox with few generic methods/properties), and few subclasses can be added on real demand, i.e. when intricated code will be reused.
>
>The question here is simple: there is a library of base VFP classes subclassed. There is another library with few of the classes subclassed used in a particular project by customer's request (for instance, textbox and label with bigger fonts).
>
>There is a generic "custom" container based control with several inner controls.
>
>I do not see a simple OOP way of having this custom control to have a particular look for this application.
>
>Setting font (and other) properties in run-time may be a solution, but it may also require code to re-position all the controls.

Why this 'custom container' cannot be a class itself?