Jim;

Would it help to have the Path set in the Config.fpw file?

Tom

>Apparently I was wrong about this being a new problem. It has been there since VFP7 (at least since SP1). It didn't show up for me because doing a build for a project with Recompile All Files checked doesn't recompile the FRX's even though it regenerates the Object field in the PJX. But when I made a minor edit to the PRG to fix a little problem I ran into while testing on VFP9, saving the PRG forced a new FRX to be generated and, apparently, that is when things got screwy.
>
>The problem appears to only affect the FXP, not the object code stored in the project! If I build an EXE or an APP and run that, then the PRG does not get an error. If I run the FXP it tells me it can't find any of the #defines from the #include file. They all result in variable not found errors.
>
>The problem does not show up if the #include includes the full path name or if it contains a pathname relative to the folder where the PRG is stored, but it can't find the file if the pathname is relative to the current folder (i.e. curdir()) or if the filename has only a file name without any path (e.g. "APPNCL.H") even though the file is located in a folder in the VFP path (i.e. set("path")).
>
>Assuming #defines are actually processed at compile time and not run time, it would appear to me that the code is generated differently for the FRX and for the Object field in the PJX and the FRX is miscompiled.
>
>This is not the way it worked in VFP6. (I've tested it.) And I don't think it was the way it worked in VFP7 before SP1, but I can't easily test that hypothesis. (It's just that, judging by the modify dates on the old FRXs, the last time the FRXs were regenerated before last month was, I believe, about the time I installed VFP7.)
>
>Looks like a bug to me.
>
>I've now put in over 8 hours chasing this down. I would appreciate it if somebody could confirm or deny my observations. I would rather not waste even more time reworking CodeBook 6 framework code to get around this problem right now if I'm on the wrong track.
>
>...Jim Hansen
>
>>It appears that in the public VFP 9 beta a change has been made to how #INCLDUE is processed for PRG files. In VFP 8 and earlier, if I wrote
>>

>>#INCLUDE "INCLUDE/APPINCL.H"
>>

>>it would find the file if was relative to the current folder or in the path even when the PRG was not in the current folder. In VFP 9 it does not find the include file and gives no error message that it could not find it. If the path is relative to the folder where the PRG is located it seems to find it OK.
>>
>>Also: In VFP 9 if I #INCLUDE a non-existant file it doesn't complain at all when I compile the PRG. VFP 7 and 8 complain about not finding the file.
>>
>>(This change broke my CodeBook 6 framework as it has that include in Utility.prg as well as several other common PRG's. I'm not sure why CodeBook is set up that way and am investigating that right now. It seems wrong to me, but apparently goes back to CodeBook 3. I'll look at it a bit more to see if it makes sense to change the PRG's to include FRAMEWRK.H instead, but this still looks to me like a change in the behavior of the #INCLUDE in VFP 9.)
>>
>>...Jim Hansen