>>>I'd like to create objects that are stored in external VCXs, but I don't want to compile them in APP or EXE.
>>>It looks like classes.dbf can handle this if I provide cLibrary, but don't provide cFileName. However, GetClassName method of cAbstractFactory class adds an external class library only if cFileName is filled.
>>>
>>>Below is the code that makes GetClassName more flexible:
>>>
>>>*{ Commented by SGM at 08:14:26 on July 20, 2000
>>>* IF NOT EMPTY(lcLibrary) AND NOT EMPTY(lcFileName)
>>>* AddLib(lcLibrary, lcFileName)
>>> IF NOT EMPTY(lcLibrary)
>>> IF EMPTY(lcFileName)
>>> AddLib(lcLibrary)
>>> ELSE
>>> AddLib(lcLibrary, lcFileName)
>>> ENDIF
>>>*} End Commenting 08:14:26 - July 20, 2000
>>
>>Be careful with deleivering external class libraries. We did this with a rather large application and found it to create alot of network I/O and instability. In fact, by compiling all our class libraries into apps and exe's, we realized a 50% performance gain. Another approach would be to use the SET CLASSLIB IN clause which is currently supported.
>
>Thanks for advise! I'll try to do that.
>
>The only problem is that all classes are based on Framework classes and putting just one VCX to a separate project will bring all related classes too. What do you do to avoid such thing?

That's actually a test question I once failed. The only thing I can suggest would be to try marking the classes you don't need as excluded from the project, because they are already compiled and available in another app or exe. When you compile your sub app or exe, you don't want to make it too fat by compiling libraries you don't need. Then again, I just failed the test question all over again! <g>