I had deleted the Visa.fxp and recompiled the project and the .prg without any noticable change. The Visa.prg code is really standalone. The project calls it as dictated by the control table and my test routine called it with hard coded parameters. I realize now that I should have checked to see if calling the routine from my test caused the fxp to be recreated.
I'm hearing that executing the code in the debugger may be a useful exercise. I suppose by the time I get another opportunity to run this down I will have forgotten what I learned! _ I' keep a copy of the thread to improve my chances - Joe
On Wed, May 25, 2016 at 9:40 AM, Ted Roche tedroche@gmail.com wrote:
Have you recompiled your project since you made this change? If you're running an APP or EXE and the control table is included inside the App/EXE, it would still have a copy of the older version of the table.
If this isn't the case, can you set a breakpoint that will trip when the code in question starts to run, for example,
"MyInputTable.DBF" $ DBF()
If this is the only place that the MyInputTable is opened.
On Wed, May 25, 2016 at 8:13 AM, Joe Yoder joe@wheypower.com wrote:
Thanks guys for the input. I had assumed there might be a function to figure out which code will run the same way Foxpro does. The problem
with
sys(16) is how to get it into the code when I don't know where it is. I concluded that I should try to give the routine something to do that will make it blow up and hopefully give away its location but before I tried that everything appeared to return to normal. (the debug stuff in the edited code started working.)
The Visa import routine is included in the project along with others like Discover and Checking. An Import control table stores the routine names along with appropriate parameters. The routines are called as my code scans the table and call the appropriate routines. When I renamed the routine I changed the name in the control table but did not add the new routine to the project. The compiler never noticed that a new routine
will
be called and does not complain or auto add the new routine. This
behavior
is expected. As far as I know this approach has nothing to do with the behavior I experienced but it may be that others may see a connection I don't.
Thanks again,
Joe
On Tue, May 24, 2016 at 1:59 PM, Gene Wirchenko genew@telus.net wrote:
At 08:23 2016-05-24, "Tracy Pearson" tracy@powerchurch.com wrote:
Joe Yoder wrote on 2016-05-24:
I have a small procedure file, visa.prg. in my current project
folder
that
imports data from .csv files. I need to support a slightly
different
format so I added some debugging code but it does not run. When I
made a
copy with a different name it worked as expected.
Is there a way to have the system tell me the location of the
running
code?
You can kinda figure some of that out through the debugger.
I would search for PRGs and Functions/Procedures with of the name you
were
calling. (Visa I would assume)
VFP doesn't complain when you have two Functions of the same name in a PRG. It runs the last one found in the PRG.
I have not tested, and do not know which will fire when you have a PRG and a Function named the same.
I was recently bit by having two methods in a class named the same.You would think that this would generate a compilation error, but it
does
not.
My debugging code was not being executed either. I only discovered it accidentally when I got desperate and startedinstrumenting the entire class and saw what looked like (and was) a duplicate name.
I suggest that you check this possibility before writing moredebugging code (which is not going to get executed anyway).
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]