>>A client is experiencing an odd problem on a number of his workstations (they run various VFP apps in support of his web site).
>>
>>VFP 9 crashes, bypassing the error handling routing, with a "Program Error" box with Cancel, Suspend, Ignore, Help buttons. In all cases, the error message is "Error reading file [file name]".
>>
>>The file name is usually an FXP. But, there are two strange things about that name:
>>1. Sometimes it has a valid drive, path and name and the file actually exists and can easily be opened and read while the error box is complaining.
>>2. At other times it has the wrong drive letter, but the path and name are OK. The drive letter is for the developer's separate standalone machine where the PRG was compiled.
>>
>>In all cases, drive letters are mapped drives. In a few cases, VFP has brought up an error window with the PRG, but that hasn't been helpful.
>>
>>If I "Suspend" and try to use the debugger to help figure things out, the watch window can't even display LINENO() and clicking different programs in the call stack doesn't change the variables in the Locals window. So, it's clear that VFP has been brought to its knees.
>>
>>Does anyone have any clues as to what might be causing this?
>>
>>Many thanks,
>>Ken Green
>
>
>Why on the earth anyone need to read FXP file? It is a compiled version of the prg file, and it is not needed (usually) when there is a VFP application EXE file built properly. EXE file contains the compiled version of the code.
>
>I guess, those programs were not included into the VFP project, or there were included, but marked as external. In this case if EXE calls the code wuth, say, /do programname/, then obviously the file cannot be reached outside the developer PC.


In this case Yuri, there are many hundreds of PRGs and changes happen a lot. So, it's more efficient to update FXPs that a massive (or a few) large EXEs.

Thanks for your thoughts,
Ken