Another (source) File Not Found error 1

[Don Child]

Hi,

This is in the context of a fairly large project that was written a few years ago. We're not sure which version it was built in, but we're opening it in VFP 9.

The

File LogStat Not found

error happens when we try to re-build the project, or run it.

The Main.prg program contains the LogStat( str ) calls. And there's a LogStat.prg file, which is already part of the project, which contains the definition for LogStat().

Since LogStat.prg is already part of the project, why would VFP complain that it isn't found? Do we have to change some setting for each .prg file in the Code tab?


Regards,

 

[GriffMG]

In the main prg, try putting a specific reference to the LogStat file

Set Procedure to d:\dev\myproject\logstat additive

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Mike Lewis]

Since LogStat.prg is already part of the project, why would VFP complain that it isn't found?

Because VFP doesn't look in the project for the file. It is looking in the default directory and in the directories along the search path. Just because a file is in the project, that doesn't mean that VFP will find it.

So you could either move the file to the directory containing your other PRGs, or keep it where it is but reference its directory by means of SET PATH ... ADDITIVE.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

It often helps to CD into the home directory of a project before a build.
Use the environment manager of the Tk Pane to make such settings for each project and it's automatically set.



Chriss

 

[Don Child]

Because VFP doesn't look in the project for the file. It is looking in the default directory and in the directories along the search path. Just because a file is in the project, that doesn't mean that VFP will find it.

So you could either move the file to the directory containing your other PRGs, or keep it where it is but reference its directory by means of SET PATH ... ADDITIVE."

This is what I need to know, thanks Mike. You're right, most of the source files are in a subfolder off the root of the project.

"It often helps to CD into the home directory of a project before a build.
Use the environment manager of the Tk Pane to make such settings for each project and it's automatically set."

I opened the project by double-clicking, and thought that would automatically include all of the settings pointing to the dependent code.

Ok, I'll give this a try first, thanks Chris.

"In the main prg, try putting a specific reference to the LogStat file

Set Procedure to d:\dev\myproject\logstat additive"

Griff, yes of course we can do an explicit SET PROCEDURE for each module that the Build complains about. But the project was already built by the previous developer, and they didn't have to do that. I'm going to try something more global, per Chris's and Mike's suggestion.

But you're right - on an individual basis, this is the right way to look at it. If we have a module referring to code in another module, than your setting is what makes sense.

 

[Chris Miller]

I've inherited many projects for which that works. If you can remote access the development environment a previous developer used, it helps to lok into the recorded command window for a repeating CD to some directory.

If you double click on a pjx that doesn't set the path to the project folder, nor do system variables and settings get set. That was enabled by the environment manager. Otherwise there wouldn't be a reason for it, would there?

Others might use a startup prg, project hooks or other means to automate that, but in itself opening a pjx from an alrady open VFP or by double click doesn't differ, you don't launch VFP from the current Windows Explorer directory, VFP9 starts with HOME() as the default folder and stays there, no matter what pjxes you open up from outside or inside. Unless you CD to some other folder.

Chriss

 

[Chris Miller]

By the way, the final EXE can still work, even though you get such build errors, because in the EXE it's true everything compiled into it is available even when addressed with wrong or no path at all.
But that's not the case within the IDE at design time.

Chriss

 

[Mike Lewis]

VFP9 starts with HOME() as the default folder and stays there, no matter what pjxes you open up from outside or inside. Unless you CD to some other folder.

Or unless you set a different default directory from Tools / Options / File Locations.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Don Child]

Roger on that, thanks for the details, Chris.


Regards,

SF.

 

[Mike Lewis]

Keep in mind that, in SET PATH, you can specify relative paths; they don't have to be absolute.

If you are working on multiple projects, create all your development directories as sub-directories of the project's default directories. Give them consistent names across projects. So you might have directories named FORMS, REPORTS, MENUS, CLASSES, etc.

Then, at the start of your main program, change to the default directory for the project, and establish the locations of the development directories, like so:

SET DEFAULT TO JUSTPATH(SYS(16))
SET PATH TO FORMS, REPORTS, MENUS, CLASSES

The point is that you can put the same code at the start of the main program for each project, and you can pretty well guarantee that VFP will find all your files.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Yes, Mike,

but that's also just a global setting, not per project. It would really be nice to let a project change default to itself. Though this also won't help in case you work on multiple projects within one IDE session.

The best time to set the right default folder would be before the build. Does the project hook have such an event? I think it has.


Chriss

 

[Mike Lewis]

Chris, that's a good point, but I think I answered it in my last post, above, which crossed with yours.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Well, code in the main.prg only deals with running it in the IDE, not with compiling/build.

Chriss

 

[Mike Lewis]

code in the main.prg only deals with running it in the IDE, not with compiling/build.

That's why I also set the search path in Tools / Options / File Locations. That's a permanent setting, given that I use the same directory structure in almost all my projects. So, when starting a session, at most I only need to CD to the project's root directory.

This approach works well for me, but I accept that there are other ways - possibly better ones - of dealing with the issue.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Don Child]

A few interesting quirks, so far:

When all of the paths ARE in place, and I try to build, there are even stranger errors, when building:

A popup error, titled

Locate File

with the mssage

Unable to find Unknown aStats


Also, in the main.ERR file, there are several errors with the following pattern:

Form ..\forms\thisform.scx has the following errors:
Unknown aStats - Undefined


aStats, as well as many of the other variables that VFP is complaining about, is defined PUBLICLY in various places. aStats is defined in main, and some of the other arrays are defined in various forms.

Obviously, the developer shouldn't have thrown in so many PUBLIC variables, and he didn't use it too much.

But I don't understand how he was able to build the project to begin with, when VFP isn't recognizing array variables that should be known to the entire application.

 

[Mike Lewis]

The way to deal with that is to include [tt]EXTERNAL ARRAY ArrayList[/tt] in the files that reference aStats. It is necessary because VFP thinks that aStats is a function, and it looking for the file where the function is defined.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Don Child]

The way to deal with that is to include EXTERNAL ARRAY ArrayList in the files that reference aStats. It is necessary because VFP thinks that aStats is a function, and it looking for the file where the function is defined."

Yep, that's the way I interpreted it. But I didnt know about the EXTERNAL ARRAY command, thanks.