Procedure executing from wrong .PRG

[1836]

HI, I have a strange situation...I have program: abc.prg that i use in many .prg's to execute a common routine. In some cases i need to execute this abc.prg routine in a
different way. As I am using this abc.prg in many parts of the system I did not add a parameter and call it with the parameter, instead I added the abc.prg as a procedure in the required .prg & changed it accordingly. Example: program XYZ.prg has the 'abc.prg' routine in the program
as a procedure. What's happening occasionaly is that when I am executing the abc.prg (do abc) in a program that does NOT have it as a procedure, expecting to execute the common abc.prg that I am using thruout the system, it ends up executing the abc procedure found in the xyz.prg.
Thank you

 

[1836]

even though one of them is embedded in it's own prg?..............whatever the case....i will change it's name
thank you

 

[Mike Lewis]

As I am using this abc.prg in many parts of the system I did not add a parameter and call it with the parameter,

Even though you're calling the routine from many places in your app, you can still add a parameter, without disturbing your existing code.

Just add a LPARAMETERS statement to the routine, specifying a logical parameter. Let the parameter be .F. for the normal situation, and .T. when you want it to execute in the "special" way.

In the routine, use PCOUNT() to test to see if the parameter has actually been received. (Or, you can use EMPTY(tlParam), where tlParam is the parameter.) If no parameter is received, assume it is .F.

That way, all your existing calls to the routine will work as before. When you want it to do the special stuff, just pass .T.as the parameter.

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[1836]

I allready changed all the programs (approx 20+, with filer() it wasn't that cumbersome), as adding a parameter in all programs whould be 'cleaner'. Thank you for this idea

 

[1836]

i felt that if it's within the .prg, there is no way that a different .prg will find it (i never had this problem before, not that i was doing something like this too often), I was hoping to hear an explanation why this whould happen (other than: "Never ever have two different routines with the same name"), but I guess this is the ONLY explanation.

 

[DSummZZZ]

Well, the explanation is that it depends on how easy the procedure is to find.
For example, if the procedure is in a currently loaded procedure file or .prg, it will be found first. Next, where can it be possibly located along the VFP search path, the operating system search patch, some other library, wherever.

The point is, if there is more than one possible way for VFP to find a procedure, it always does. I've been bitten and I would be willing to bet anyone who frequents this forum has been bitten too.

Like Mike implied, it just ain't a good idea to have more than one procedure with the same name anywhere.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[mmerlinn]

I have had the same problem happen to me.

I have an app I run with abc.prg embedded in it. Same proc is embedded in another program. Somewhere along the way abc.prg gets updated and rebuilt in one of the programs but not the other.

Then when I run prog1, everything works as expected. When I close prog1, but not FP, then run prog2, prog2 uses the copy in prog1 instead even though prog1 has been exited with all items released. It does not matter which was run first, the result is always the same.

So, to prevent that from happening, I now always restart FP from scratch whenever I run any FP app. In my case it just is not feasible to change proc names every time I edit them. And neither is it feasible to rebuild all apps containing them every time I change abc.prg.

Not sure why this happens, but it appears that abc.prg from prog1 is kept alive by FP even though the app containing it has been closed down.

mmerlinn

http://mmerlinn.com

"We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding. Answering questions for careless and sloppy thinkers is not rewarding." - Eric Steven Raymond

 

[1836]

you are right, once i recompiled all the programs the problem was resolved