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]
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]
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]
On Thu, May 26, 2016 at 12:27 AM, Joe Yoder joe@wheypower.com wrote:
I'm hearing that executing the code in the debugger may be a useful exercise.
The debugger is a very powerful tool. I recall years ago having to step-by-step through the code when debugging a problem with the framework I was using, and I learned a great deal about the framework and appreciated much more how it worked. I also found the bug and got the author to fix it!
The debugger is well worth learning.
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
The debugger is your friend when you are using it and find a value from the command window is still being referenced.
Still have not forgotten that time sink.
On Thu, May 26, 2016 at 8:47 AM, Ted Roche tedroche@gmail.com wrote:
On Thu, May 26, 2016 at 12:27 AM, Joe Yoder joe@wheypower.com wrote:
I'm hearing that executing the code in the debugger may be a useful exercise.
The debugger is a very powerful tool. I recall years ago having to step-by-step through the code when debugging a problem with the framework I was using, and I learned a great deal about the framework and appreciated much more how it worked. I also found the bug and got the author to fix it!
The debugger is well worth learning.
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
-- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com
[excessive quoting removed by server]
Hi Usaly a code does not create a fxp file, s fxp file is created by either do myprg which will create if not yet exists a myprg.fxp or you can issue compile 'myprg' which will also only create a myprg.fxp in both cases VFP is running the myprg.fxp. To find out, in case you have two files myprg.fxp in your environment sys(16) is your friend. I would set a messagebox containing the sys(16) in the init of both / all myprg.prg you dont have to worry about the .fxp file(s) they are constructed by VFP rgds Koen
Op donderdag 26 mei 2016 heeft Joe Yoder joe@wheypower.com het volgende geschreven:
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 javascript:;> 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
javascript:;> 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
javascript:;> wrote:
At 08:23 2016-05-24, "Tracy Pearson" <tracy@powerchurch.com
javascript:;> 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 thesame.
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 andstarted
instrumenting 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]
-
Joe Yoder -
Koen Piller -
Stephen Russell -
Ted Roche