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 <j...@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 <ge...@telus.net> wrote: > >> At 08:23 2016-05-24, "Tracy Pearson" <tr...@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 started >> instrumenting the entire class and saw what looked like (and was) a >> duplicate name. >> >> I suggest that you check this possibility before writing more >> debugging code (which is not going to get executed anyway). >> >> Sincerely, >> >> Gene Wirchenko >> >> [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cacw6n4u9-frwyh37gfyhnmz_dmmnuefy6fdw8xmazm+suxk...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
