>Alright, I am currently in programmer purgatory. It has been tasked of me to modify a project that was developed by someone else. Bad blood prevents us from consulting with the original programmer. His vastly different programming style from mine means he didn't do much of anything the way I would have done it, and I am having problems figuring some things out.
Ah, the programming chameleon's initial troubles :). Eventually you get under anyone's skin and learn how they think. You don't get to like it, but it just gets easier each time.
>The big issue is data location. When I compile, the resulting executable reads data from a test location, not the location of the real data (or of the database that is in the project). I cannot, for the life of me, figure out what is telling the program to look in this location. (If it were me, I would have had a public variable in the main program file, but no such luck here.) What really gets me is that I've checked out the forms and I can't find anything in the BeforeOpenTables method. How can somebody have a variable data location and not use BeforeOpenTables?!
Quite simple - the DBCs are open by name, there where they are found in the VFP's path, unless...
>I'm just at a total loss of where to look here. I've even used the Windows file search feature to find the test path in any of the files in the project directory. No dice.
Toss your dice into the compiled code, and open it in a hex editor. Chances are that the compiled code refers to the development directory, and you may find references to it there. This path will be used if accessible. I've seen this in VFP6 SP3, and if it was fixed in SP5 I wouldn't have noticed, because a workaround (goApp.SetEnv(this) being called from each DE's BeforeOpenTables) was already in each form when SP5 came.
Now I don't know if this was fixed in VFP7 because I'm using a framework which uses session class to create its DEs and doesn't use forms at all (it's all in the vcxes).
>Btw, I've been programming in FoxPro for over seven years (in amongst other kinds of projects), so I know my way around a FoxPro project reasonably well...though clearly not this FoxPro project. I don't know whether to feel humbled or angry.
After almost twice as many years, I know the feeling never leaves you... once you get to fix someone else's mess, you may lose a lot of hair. Still, this is nothing big, because it'll never happen in production; the user won't have the dbc with the same name and path as your test one is, and VFP will happily find the proper one on its path. It's just that you're running your tests on a wrong set of data, and that can be fixed.
