Vfp error locating config file

Board index » VFP. The whole of VS6 including vfp6 was loaded onto my cdrive. Not a network drive, this is a standalone setup. The VS6 sp3 has been applied as well. Neither before nor after the application of the sp has FoxPro run. I also tried reinstalling.

On each occasion it comes up with: 'Error locating config file--bad path? Any help would be gratefully appreciated. I located a config. Now what remains is Pavels question: What commands report this bug? The second answer may be deducted from the first.

So do you have an error handler telling you the location of the error? If not it's time to add error handling to your application to find out what code is causing this. That mostly answers the question. There is an error logging process in the application. Client reporting the error when loading some vfp forms in the application.

And it throws vfp system error handler. Not running our error logging process. I think this may happen because of environment settings in the client machine. The error message indicates that it is unable to read the quit. But the problem is when this error happens it is trying to read the quit.

OK, the path is really stored in the EXE and it contains the real folder of the quit. If the quit. Application should ignore it, as well I would recommend to append the QUIT. FXP to execute, so that's not the problem. Still a receommendation. If quit. So there seems something different is going on. If so, why don't you include them in your EXE? If you exclude the quit.

FXP and execute that file. If that client has restricted temp dirs in some way that won't work and may result in the file read error. The error is not saying it can't find the file, but it can't read it, perhaps it can't execute it.

Perhaps you just need to get your project straight, include quit and anything you have in the EXE will execute. You will only need external files, if the files are subject to change or differ from client to client. I am extreamly sorry to say that the. I just want to give the idea that program is calling when the application quits. The name is dmQuit. Not Quit. And also dmQuit. And user has full access to the TMP folder in config. Well, nothing of that is addressing the error is saying it can't READ the file, not that it doesn't exist.

If all is well in the project, then a recompile and reinstall of the EXE is maybe the only thing you need. Also the error is not explainable at all, if the dmQuit. What does the project manager say is the location of dmQuit. When you click on it in the project manager, what does the project manager window show in it's status bar as Path?

I would not say the error isn't explainable. If the QUIT. PRG is included in the project then we are much closer Even the!. PRG is correct program name. The help topic on reserved words says "When programming, avoid using reserved words as names for window, table, or field names.

If you use a reserved word as a name, it might generate a syntax error. And I would extend that recommendation to any names. It's not technically needed, but is bad style to use reserved words for your own names. That recommendation is cautious and also tells no examples, where it applies, but what speaks against caution?

If "reserved words" would really be reserved then you may forget about the backward compatibility. The help is inaccurate in many other places and this topic seems to be prepared by absolute beginner. Of course, you may write unreadable code when using command names as variable names etc.

And some language elements are "reserved even more" than command names, e. Yes, you maight generate syntax error in some rare situations but such problem is immediatelly identified by the compiler and the number of mistakes is minimized. But FoxPro language has other gotchas. Much more dangerous than reserved words usage is e. So the help isn't dogma to me and I don't see any reason to implement all its recommendation word by word.

And within a string you can write anything. It's not a big restriction to not use reserved words, as you can always prefix them or add a suffix. Not dmQuit. And the file path of dmQuit. This is OK. So are you able to create a small project containing just your dmQuit. I think the editor must accept the filename to edit as an argument. The internal editor may not be the best, but you can hook in into editor events. Search Christof Lange's isx. You can also extend possibilites via keyboard makros and intellisense manager.

In regard to parens for example, the vfp9 editor will highlight the complete section back to the opening bracket, when you write a closing bracket. Bye, Olaf. Bagby, First of all, welcome to the forum, and to Visual FoxPro. I don't think anyone has mentioned that you can include all the SET settings in your config file, but the syntax is slightly different.

Under Windows, you can simply switch to a different editor, edit your code, save it, switch back to VFP, and run it. VFP uses the date stamp to decide whether to compile the program. VFP doesn't have to know that the editing was done externally. TEDIT was obviously more important before we had task-switching. You mentioned WordStar. My editor of choice was Sidekick. Hope this helps. Olaf, that's actually the first thing I tried. I'm also new to Win7, having finally switched over last month from XP because I got a system that could.

May still go back to XP, mutter, mutter. I didn't know if those things were still true of Notepad in Win7 Dan, the new things are kinda piling up here.

I did want a familiar environment with no surprises or mysteries while I debug my sloppy code. I do intend to get into the Foxpro editor further, I'd just rather not do that right now. Mike, thanks for the welcome and the tip! The editor doesn't actually come into play when you're debugging, to be honest. That's done in the debugger. This is the first time you've mentioned Win7. I'm wondering if the increased security might be keeping VFP from launching an external exe? Do you begin to see how seldom this feature is used?

I rarely build applications, so I'm basically just dealing with scripts -- the prg files themselves. When an error occurs, the. I'd like to change that to my editor-of-choice. Well, regardless. That's how the help-file says to do it, and it doesn't work. Apparently this isn't something I'm doing wrong, it just doesn't work. Last time I used it was in VFP7. That feature might really be deprecated without further notice.

I'll see if it's an OS issue, but I trust dan on running vfp as admin also didn't work.