>I have a large VFP 9 application using 9 VCX Class files. It has worked fine for some time till I added the 9th VCX. It was copied from another project but I checked and all the references are set to local VCX Classes, etc. The problem is a container object in the VCX that is added to a form at runtime to show help messages. It can be called at any time from any form though an internally developed help system. We set it to auto load because the system has over 300 forms.
>
>The object loads with:
>
>

if vartype(oForm.cntHelpMsg) <> 'O'
>       oform.NewObject("cntHelpMsg","cntHelpMsg","j5w.vcx")   <-- line causing crash.
>       oForm.cntHelpMsg.Zorder(0)
>endif

>
>Sometimes users get the error: Class library file (path) \j5w.vcx not found. The only fix I can find is to place the J5W.VCX file into the (path) folder. Other places where it is used do not have a problem.
>
>Ideas?

What if you did the following:

In main program add:

_ProgPath = ADDBS(JUSTPATH(FULLPATH(SYS(16, 0))))

If we assume the VCX files are separate from EXE/APP files and are in main program folder, then we reference the VCX relative to the folder.

oform.NewObject("cntHelpMsg","cntHelpMsg","j5w.vcx")

becomes

oform.NewObject("cntHelpMsg","cntHelpMsg",_ProgPath+"j5w.vcx")

of course this might require you to change a lot of code... Another alternative is to SET PATH and add the folder in which the main EXE is stored (e.g. what I've stored in _ProgPath). Personally I don't like SET PATH much -- it was a cause for headaches because it tended to mask problems (data files or program files in wrong location). One situation I'd run into was a network install. Normally we had data files in subdirectory DATA and APP files in APP folder. For some reason some DBFs were copied into the APP and a few other folders (not sure why -- obviously the enduser will deny any responsibility -- "they just appeared there one day"). What happened one day was when directory access rights got mucked up and some users had access to DATA directory and others didn't. Those users that didn't have access to access DATA folders ended up opening files in one of the folders listed in the SET PATH -- which turned out to be the copy in the APP folder. There were *no* errors.-- just a different DBF being accessed -- which of course meant there started to be some inconsistencies in the data depending on the user accessing the system..