Error -> "File does not exist" on calling any function of .prg file

[KALP1]

I have put all my generic functions in 1 .prg file(say named it 'General_functions') and in the main program I called
Do General_Functions
In all other programs I just call a function(say Get_Running_year()) defined in General_functions.prg .

Problem is that in some cases not always, I get error "File Get_Running_year.Prg does not exist."
What might be the reason for this as calling in the main prg, all functions defined in General_functions will be made available.

I have tried "Set procedure to General_functions additive" ,then too sometime I get this error.

Is there any other way to do that.

 

[Mike Lewis]

I recall sometimes VFP had problems with long Function/Procs names.

Function and procedure names can be up to 254 characters. [tt]Get_Running_year[/tt] is well within that.

But who knows?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[KALP1]

1 point is worth noting here is -
I have this problem in IDE. I haven't included it in Exe hoping that same problem could be faced by users.
Shall I test it in executable as Olaf has mentioned it could be the problem of IDE.

 

[Olaf Doschke]

Is this a forum or a chat? Has anyone thought about any SET PROCEDURE anywhere done without the option ADDITIVE? You can overwrite what procedures you set, if you forget that. CLEAR ALL or CLEAR PROGRAM is not the only way to lose one prg from the list.

So use Code References to find all places where SET PROCEDURE is done and look out for those not adding prgs or frxes ADDITIVE.
Also since you say you ESC, what is ON('ESCAPE')?

Bye, Olaf.

 

[GriffMG]

The OP already said that Olaf

By code references I have thoroughly checked whether additive clause is missing in set procedure or not. I haven't found it anywhere.
As I have put very generic functions in that prg,so they are called from many programs.While working sometimes that error message prompts up.

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. ​

 

[Olaf Doschke]

Well, if you look thoroughly for SET PROCEDURE of that single prg, then you don't find SET PROCEDURE to other prg, but let's say this is checked and not the culprit. Then ON('ESCAPE') remains, if this is the key observation, also the unload of the form in question and it's base class etc. You can do a breakpoint on condition SET('PROCEDURE') does not contain the prg in question and hope this breakpoint will point at the exact location of where this prg is lost.

Bye, Olaf.

 

[GriffMG]

Sounds like a plan

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. ​

 

[TamarGranor]

I strongly recommend ditching procedure files entirely. Put each procedure/function in its own PRG named with the name of the procedure/function and never worry about this kind of stuff again.

I wrote a tool to programmatically turn a procedure file into separate PRGs. I can send it to you if you send me an email address.

Tamar

 

[KALP1]

Tamar, my emailid is kalp.rodes@gmail.com

 

[Mike Lewis]

Has anyone thought about any SET PROCEDURE anywhere done without the option ADDITIVE?

Yes. I raised exactly that point about 20 posts ago. I don't think the OP picked it up though.

Miie



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Kalpi,

You might like to know that it is against forum policy to post email addresses. Nor is it necessary in this case. You can easily contact Tamar privately through the Tomorrow Solutions website.

Also, the tool that she is generously offering to share with you could well be useful. But you don't need it in order to try out her suggestion. Just copy and paste the relevant function into its own PRG file, and give that file the same name as the function. Provided your calling program can find the file, it should be able to execute the function.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

Mike, he did and responded thus:

By code references I have thoroughly checked whether additive clause is missing in set procedure or not. I haven't found it anywhere.

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. ​

 

[KALP1]

Sorry Mike for breaking forum rules. Will take care of that next time.

I have not put any procedure ON('ESCAPE') or form's unload event.

 

[Olaf Doschke]

I never told you to look for ON('ESCAPE'), you should watch that, meaning you put it as watch expression in the watch window in the debugger and debug at that step failing. It is therefore executed its result is displayed.

SET('Setting') is in general the lookup of what has been SET SETTING TO xyz, it displays xyz, so you know what has been set. In case of SET('PROCEDURE') that is cumulative because of the ADDITIVE. I trust you put ADDITIVE everwhere you added you prg, but did you look for any other SET PROCEDURE. It is just one cumulative setting with many PRGs like SET PATH does store many PATHs, so any SET PROCEDURE can remove your PRG file from the list.

In regard of ESCape key functionality there has to be ON ESCAPE ... or ON KEY LABEL ESC... You might also simply have a button for cancelling, which has its CANCEL property set .T. and code in there could unset/reset procedure or caise that indirectly. Again: Don't look out for the command CANCEL now, CANCEL is not only a command but also a property name of buttons, which should by default react to ESC, their Click event code runs, when you click them or press ESC.

You will have some code somewhere, which changes SET('PROCEDURE'), otherwise it does not get lost.

Bye, Olaf.

 

[KALP1]

Now I got what you say.


Is there only 1 way in which Set("Procedure") functions gets lost i.e. Set Procedure To without "additive" keyword or any other reason. As for additive keyword I have checked everywhere.

Will put set('Procedure') in watch window and wait when this error comes again

 

[Dan Freeman]

You have me curious here: with all this searching for SET PROCEDURE how often are you using it?

Most of us SET PROC once at application startup and never fiddle with it. Are you repeatedly issuing SET PROC TO ... ADDITIVE are you doing it with the same PROC files? How many do you end up with? Which one should VFP use?

This could just be a code organization shortcoming that confuses VFP.

 

[KALP1]

I am using Set Procedure to in 7-8 places in my application. 1 is in my main program for generalised functions and other are specific to some utilities. For ex., for Entry and Edit, I keep 2 diff. programs and some common procedure for the 2 in 3rd program. So I use Set Procedure to 3rd program in both Entry and Edit Programs.
I don't know my approach is correct or not. But I use it in this way.

 

[Mike Lewis]

Your approach is "correct", in the sense that it will work as you intended. But, in my opinion, it is not ideal. You should either reduce the number of procedure files, or use Tamar's suggestion of putting each function / procedure in its own file (in which case you wouldn't need SET PROCEDURE).

I usually have two procedure files: one for generic utilities that I use across all my apps (e.g. calculating the width of a string in a given font); and one for routines that are specific to the app in question. I open both of those (using SET PROCEDURE) near the start of the main program. But that's just my preference. By all means continue to do it the way you are doing.

The important point - which we have mentioned now several times - is that each time you use SET PROCEDURE, you should include the ADDITIVE keyword. If you don't, the last procedure file that you open will replace all the previous ones, which would explain the behaviour you are seeing. (Actually, you don't need ADDITIVE for the very first SET PROCEDURE, but it does no harm to include it.)

Have you tried Tamar's suggestion yet - putting the function in question in its own PRG file?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[KALP1]

Actually, firstly I had all functions in separate PRGs and every thing was working fine.
In order to maintain my programs in structured way, I had clubbed generalised functions in 1 program file and used "SET Procedure to". So there is no question that Tamar's suggestion will not work. If problem continues, will revert back to separate PRGs.
** In last 2 days I haven't got this error.

 

[Olaf Doschke]

Tamar's suggestion will always work, because even functions depending on each other put into their own separate PRG files will find each other without SET PROCEDURE, by the PRG name. It also has the advantage to only need to include all PRGs really using each other or being used from any main project form or class or anything.

I'm still not in that camp, as I prefer a certain grouping for maintenance and organisation. You can always argue a folder can replace that grouping, too, but then you will need another project manager, because it puts all similar elements (forms/classlibs) together without a folder structure and to me that clutter isn't worth that advantage. Like you hint you do have a central place where all SET PROCEDURE take place, I too have that and its meta data driven, and that meta data is taken from the pjx. In my company framework this is done via a prg extracting all classlib names into a dbf, in my personal core coding I use a project hook setting all paths and classlibs up during load of a pjx, not depending on aany dbf, just oriented fully on the project itself.

And besides all that, the problem really only exists within the IDE, at runtime anything included inside the EXE is found even when addressed with a wrong path. That's heaven and hell at the same time sometimes, but mostly you can live with it.

Bye, Olaf.

 

[JackTheC]

By the way, sometimes using a RUN | ! Command somewhere in the program can make loose your procedures set in SET PROCEDURE and thus resulting in Get_Running_year.Prg does not exist.