>As far as what I am trying to do, this might take a while to explain. I have a project that includes six visual classes (VCX) into my project. In VFP 3.0, I would SET PATH to the directories where these VCX's reside. In my application, I would SET CLASSLIB TO myclass.vcx ADDITVE, and all worked fine. Of couse once the application has been compiled to an EXE and moved out to the network, the actual directories for which the VCX's reside no longer exist.
>
>In my DBC, I have use the CREATEOBJECT() to instatiate an object needed to generate a primary key. In VFP 3.0, I have no problem with this. In VFP 5.0, it cannot find the class to instiate the object. It give me the following error with "Locate class" in the window title when the CREATEOBJECT() is encountered:
>
>"Error instatiating class. Cannot find
myclass.vcx."
>
>Buttons on the window include Locate..., Ignore, Cancel, and Help. No matter what the user does the program gets caught up in a loop. The funny thing is that typing FILE("myapp.vcx") in the Watch Window at the point of error give me True. I cannot remember, but it seemed that doing a SET CLASSLIB myclass IN myapp got around this error.
Is MyApp the name of the currently executing application? If so, of course it can't close during execution.
>This leads me to the error that I discussed earlier where myapp is still open. It seems to me that the RELEASE CLASSLIB myclass IN myapp is the answer, but this command does work. I think it is a bug in FoxPro or a Doc error.
Not a documentation error, but possibly related to a known FoxPro error.
>What do you think? Can you think of any workarounds? Of course, the user is not affected by the "myapp still open" error, but it makes development work a real pain.
What drive on the development system is all of your code located on? If it is all on c:, the following does not apply. However, if any of it is on another drive (d:, e:, f:, whereever), that *original* drive will be noted in the final .exe/.app and FoxPro will search for that drive *first* before checking the .exe/.app itself. There is no way to shorcircuit this behaviour - if an application is to distributed, in general all development components must reside on the development machine's c: drive. The usual symptom is a message "Cannot read from drive d:" or whatever the drive was that held the component, but you may have a different variant on it.
This is documented in the June 1997 issue of FoxPro Advisor, incidentally.
In general, make all references to outside components as non-specific as possible in the code - the project will cover you in the development process, and assuming you've included all your components, the .exe should have them all built in.
