How did this Temp File pathname get into a project ? 1

[vfp7guy]

One of our client installations recently had a frequent intermittent error "Error reading file..."
Filename was "c:\docume~1\<username>\locals~1\temp\<progname.fxp>"

I anticipate the reported filename was the DOS 8.3 version of the following:
c:\Documents and Settings\<username>\LocalSettings\Temp\<progname.fxp>

The <username> specification was the network name for one of our inhouse developer's computers.

Suspecting that the user's error was while trying to read a VFP temporary file (e.g., cursor) in a non-existent directory on that user's computer, I scanned the distributed EXEs for the character string specified in the <username>. I found one EXE that had the above path in the code. I USEd the associated PJX file and found 6 entries with that same character string in the .OBJECTS field (tucked in near the bottom ofl the binary code). These records were for 3 PRGs, 2 SCXs and 1 VCX for that PJX.

Our development directory is on our inhouse network and projects are rebuilt by the developers in that directory.

I rebuilt the EXE (with Recompile All files) and searched again for the same string and it was now gone from the EXE and the associated PJX entries.

I suspect that inclusion of that specific pathname somehow got inserted by the programmer who last built that project.

I have 2 questions:
(1) How did that path get inserted when the programmer rebuilt that project, but not the other nnn times the same programmer rebuilds projects.
(2) Why does the end user only get this error intermittently ?

Any clarification would be appreciated.

 

[Olaf Doschke]

If a class subclasses another class which is not included so far in the project, that could be automagically included into the project at compilation time, and therefore modify the pjx. And if that class is found to be in current SET("PATH") that may also be included instead of the one at the appropriate path.

Well, I've just now removed (not deleted) the most basic vcx from my project and rebuilt => There it is again, found at compilation and re-added to the pjx without any message from vfp.

That directory you mentioned is also likely to be, what GETENV("TEMP") or SYS(2023) give you. So it can also be code that generates some PRG temporarily and compiles/executes it. Perhaps search for such code, too.

Bye, Olaf.

 

[vfp7guy]

Thanks Olaf, but I scanned for that string in all VCXs used by that PJX and couldn't find it. However, it may have been inserted from when the other programmer recompiled, and was cleared when I rebuilt.

If it arises again, I will archive the entire development directory and maybe find the time to locate the actual originating place for this.

One of the other programmers says that he has seen this happen before, but never found the cause. I suspect it may be due to some environment setting in the programmer's VFP when the project got recompiled.

 

[GriffMG]

I may have missed the point, but VFP does tend to keep the paths to it's various tables as part of the data environment for forms and reports.

When this first tripped me up in version 3, I was mildly miffed - particularly by the MS response at the time, write an init function for each form etc to correct the problem.

I found that writing a simple program, which I run before compilation, removing or replacing the file path references works well enough.

Basically, I open the project file, then each form or report file and replace any path with something silly that could not, or probably will not, exist at runtime.

It's a bit long and not well written - if you want a copy send me an e-mail 'griff at finedata.com' replacing the obvious with a commercial at sign.

Regards

Griff
Keep [Smile]ing

 

[rkolva]

We had a similar problem with an app that needed to dynamically switch between 2 data paths at runtime. In our case we discovered that the Data Environment's cursor path referenced the directory/database used the last time we ran the app was compiled into the exe and the app wouldn't switch to the second data directory. We eventually removed the DE from all forms and now set up our data in the load and unload events/methods. I guess its just as well since you can't subclass the DE anyhow. Don't know if your situation is similar but thought it might be worth a look.

Ralph

 

[medic]

vfp7guy,

That scenario can always happen when a VFP project is accessed through the network. It's more likely that when the programmer created those modules (adding them to the project), the programmer saved the files on the local drive... not where the rest of the projects files are located.
If those modules were previously created with the rest of the project files, the programmer may have copied them first to the local drive (before working on them), and modified the path to those program files...forgetting to re-create the path back to the original files.

 

[vfp7guy]

I think your suggestions are on the right track ... regarding the network. We have our master source library on the network, controlled by an elaborate in-house-written Source Control system. A programmer can check-out a file (SCX, PRG, FRX, etc.) to his local development directory for revision. This flags that file so no other programmer can check it out, and everyone can see who has what checked out. (There are also automatic update options that will ensure all of your source is up-to-date with the master library.)

Each programmer will recompile PJXs on his local directory for basic testing, then will check-in the revised source back to the network master directory, which now resets the checkout flag. Final recompile is then done by that programmer in the master network directory.

I am trying to determine where some of these items may get introduced, depending on the programmer's local environment at that time. Is it in the returned source code, or in the network rebuilding of the project? Or both ?

 

[vfp7guy]

I forgot to mention in my last response that our check-in process in our Source Control system also strips out any embedded printer codes when returning FRX files.

 

[medic]

The programmer may have temporarily used more than one work folder in the local drive. The affected files may have been placed in another folder outside the one where the PJX file was copied into. In this case, the affected files retain their original local path when the project file is rebuilt at the network folder.

 

[medic]

...and yeah, it's in the returned source code.

 

[Olaf Doschke]

...and yeah, it's in the returned source code.

Yes, that's it! I should have come to this conclusion by what you said initially.

If it's FRXs, like in your case, the expected paths should be in the PJX table. Because Foxpr/the project manager doesn't find the PRGs/FRXs in these paths he searches in the several other locations, so also in the users TEMP dir. But just because it shows up "C:\Documents and Settings\<username>\LocalSettings\Temp\<progname.fxp>" doesn't mean it was searched there at first, that was perhaps just the last path searched. It's almost a bug, it should get on the Universalthread Wishlist that in these cases the original path searched should be displayed, that should always be a better information on where to search!

By the way: If it was a class that wasn't found you should search in the classloc field of the VCX tables of the project. If a whole classlib is missing you'd of course find that path in the PJX table again.

Bye, Olaf.