>You may have encountered a 'feature' of VFP that we ran into last summer in our early CodeBook work. We would do our development on drive letter 'E' and build an exec that was to run anywhere --- but some of the classlibs would fail to be located (class xxx not instantiated locate/die/or wait) unless the exe ran on an 'E' drive (or what ever original drive letter was involved). We found by poking around inside the VCX's (and later with BMP referenced in .picture properties of form classes/and SCX's amoung others) that the path information in the CLASSLOC or properties memo fields was not always relative but ABSOLUTE'. The exact 'path' in the CLASSLOC and other fields of the VCX would change (we didn't try to understand how or why after a month of insanity but found the drag and drop between classlibs on differ drives and the CLASSBROWSER were often the most recent actions) and resorted to writting a project relocator that 'fixed' all the drive related pathing the CLASSLOC,
>properties, RESERVED8, and a lot of other places. We now always run out PROJMOVE to 'relativise' the classes (and stored procedures in the DBC's - just found that one) when we plan on relocating the project or are preping for a exe build.. One other note for the CodeBook users -- always always always 'clean-up' the project and zap metadata and run once with do main with debug before attempting a BUILD. Both the project table and metadata have memories and ignore deleted rows in the metadata repopulate process -- nothing like having the appl look for a classlib you haven't had in the project for a month at exe time.
>Hope this helps some.

In the tests I made, I used a class for buttons written "by hand". Just to be sure that the test doesn't depend on the information stored in vcx. (In fact, I tested it with VCX also, the same results :().

So, it's a problem with the project and BUILD APP/EXE, not VCX/other.

Vlad