>Using Mark’s description of the problem, I set up some tests. I created a class library called base.vcx that contains only a single class, that being a form (‘frmTest’). I then created a form (‘Form1’) based upon my form class contained in base.vcx.
>
>I created a simple program to test some theories. Here's the test program:
>
>SET CLASSLIB TO base.vcx
>f = CREATEOBJECT('frmTest')
>IF VARTYPE(f) = 'O'
> ? PEMSTATUS (f,'show',5)
> ? PEMSTATUS(f,'release',5)
>ENDIF
>RELEASE f
>DO FORM Form1
>

Classlib has 0 to do with this - the problem here is the SCX/SCT, and there are likely hard-coded paths to some of your controls in there. Open up your .SCX in there, and look at the field "CLASSLOC" - in there you will find a bunch of specific path references that you'd need to fix up to make work with the scheme you're attempting to use. Essentially, you've made it impossible for VFP to fix the reference up at runtime because you've bound the SCX into the executable, and the path reference isn't being resolved. You want to remove all path references; I'm not sure of the exact notation for a file that needs to be runtime-resolved by being resident in another .EXE

>Keep in mind that all code, forms, and classes are stored in the same directory.
>
>I created a project that has my simple program as the main, all forms and classes included, and created a Win32 executable. When this executable is run from the development directory, everything works just fine. When I copy this executable to another directory, everything still works fine.
>
>I excluded the classes and recompiled. When run in the development directory, everything still worked without incident. However, when I copied the executable to another directory, interesting things started to happen. FoxPro first says base.vcx does not exist and asks for an ignore/cancel. It then complains that it cannot create the requested object. To top it off, FoxPro states it has an error instantiating a class. Pointing VFP to the base.vcx file at this points allows VFP to correct the current error and finish execution. If I copy base.vcx into the new directory, everything again works like a champ.
>
>My next step was to compile base.vcx into a separate executable (‘Classes.exe’) and remove base.vcx from the test directory. I replaced base.vcx with classes.exe and I modified the first line of the program to read as follows:
>
>SET CLASSLIB TO base.vcx IN classes.exe
>
>In this case, everything works fine until you reach the DO FORM. At this point, FoxPro again complains that it cannot find base.vcx and asks the user to locate it. I pointed VFP to the development directory and execution completed without incident. As expected, if I do not point VFP to the development directory, the program errors out. If I copy base.vcx into the new directory, the program works without problem.
>
>For what it’s worth, I also used the following as a replacement for the SET CLASSLIB and the CREATEOBJECT:
>
>f =NEWOBJECT(‘frmTest’,’base.vcx’,’classes.exe’)
>
>And as expect, the object was created without problem. The problem still remained with the DO FORM, however.
>
>It seems that the DO FORM command is what is causing the problem in my tests (and possibly Mark's code.) FoxPro appears to be looking for base.vcx on its own, regardless of the SET CLASSLIB settings. I have also experienced the DO FORM not respecting the SET CLASSLIB settings in some of my own projects when I exclude the class libraries files.
>
>Mark, have you tried keeping the classes separate? If so, what kinds of successes have you had or not had with this method?