Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Command History not saved if VFP closed by shutdown

rbeitler

IS-IT--Management
Sep 17, 2003
5
US
I use VFP IDE on our server. If I use QUIT in command window, command history is saved properly. This is also true if use close the IDE with the "X" button, or right click in taskbar and choose close window.

However, if the computer is rebooted by someone else (like for updates, etc) the command history is not saved. I am guessing the vfp9.exe process is terminated so it is not running the normal shutdown routine. This is very frustrating when you have days or weeks of command history that you need to see!

Has anyone else seen this behavior, and is there a way to fix it? Perhaps using ON SHUTDOWN?
 
If you are concerned about saving history, just keep in mind that your history is stored in a simple PRG file called _Command.Prg. So, you can periodically back it up, or as you suggested, perhaps make a copy on shutdown.
 
That's long been a problem. It's frustrating when VFP crashes or the computer reboots for an update and you lose those commands. The 64K limit has also been bothersome. There are likely solutions like setting up a macro to save the command history to a file (besides _command.prg). Also, you can simply quit and restart at lunch and when you leave work. Or, heck, every damn hour. I'm jumping back and forth between projects, so I switch folders with a CD, open various VFP forms, classes, and reports, etc., but before I do, I use an on key label setup of F7 that does this:

on key label F7 keyboard "* " + cdow(date()) + " " + ttoc(datetime()) && + "(Enter}"

This lets me find the switches when I look back over the code and is helpful with billing, since I sometimes forget to record my start/stop times. At least I have something to go on.
 
When the machine is rebooted that is running VFP IDE, the VFP running process is terminated by the OS. This is not an orderly shutdown that would allow the command history to be saved. You would need to use a method as described above that the user can trigger to save the contents to a file. You might also add a timer to the _SCREEN that would do this automatically in an interval that is started when VFP is started.
 
If the shutdown would simply cause no save of the command history, you would still have the history up to the last start of VFP. If your _command.prg (as mentioned by Joe) is emptied, then it's not just true the shutdown kills the process without an effect on the commdn history.

I would look, whether your command history is really emptied or just not found or it's loaded from another directrory and your last or at least a quite recent state still exists elsewhere.

Much of what has alredy been said can be found in the help topic of the Command Window in this paragraph
Command Window (Visual FoxPro)

Persistence of Contents​


The contents of the Command window are saved to a file, _command.prg, automatically unless the noRecentDocHistory system policy is enabled or you are not using a FoxUser resource file. You can clear the window by selecting Clear from the Command Window shortcut menu. To enable its use by multiple instances of Visual FoxPro, the file is only read when starting Visual FoxPro, and written when exiting Visual FoxPro. The file is located in the same directory as the FoxUser resource file. You can determine or change the location of the resource file from the Options dialog box, File Locations tab, or via language using SET("RESOURCE") or SET RESOURCE respectively.
It also literally tells about a case that can be the root cause of loosing the history: If you clear the command window with CTRL+A and DEL or with the context menu "Clear" and think you just clear the window for the current session, then close VFP normally, you actually shorten the _command.prg, the prg file really is just and simply the whole content of the Command Window at the moment of saving, there is no such thing as appending to _command.prg or keeping a history like a transction log.

Knowing this, going forward you better backup your command history yourself and also take it as a way to redigate it to what you really want and need.

I also like to point out that _command.prg also was a topic in the thread https://www.tek-tips.com/threads/settings-in-config-fpw.1832550/ that was about wanting to have several _command.prg file or even individual names.

So also when you switch the location of foxuser.dbf or delete and recreate it, but not in the same place but perhaps the default location you switch to another state of the _command.prg stored there or "empty" it indirectly. That's also a case where you can still find an untouched recent version. Just to be clear: If you recreate the foxuser.dbf to recover from a corrupt state of that table, you don't also delete the _command.prg, but when that changes the location of the foxuser you also change the location and thereby state of the _command.prg
 
Last edited:
Thank you for all the replies.
I also keep my own history file, periodically I add a line like:
* 2/26/2025 Updated \u\work\_command
Then I search backward for the last comment I have like this, do a Ctrl+Shift+End to select everything from that point, and copy and past to my history file. It is invaluable to have everything going back to rerun old queries, etc.
So OS shutdowns are my only blind spot... I do find myself quitting and restarting to make sure it gets saved to _command.prg, I guess I will try to make it a end of day habit.

Does anyone know if ON SHUTDOWN code would be executed if the OS tries to end the vfp.exe process? And even if it did, if the "fresh" commands are not in _command.prg how would vfp code get it from the command window? Maybe simply having a QUIT in ON SHUTDOWN would execute the normal routine and save the history? If I get time I will give it a try.
 
No offense, but why are OS shutdowns a problem? You don't let Windows decide when to do them, do you?
When it want to update itself I always shut down all programs before I reboot.
 

Part and Inventory Search

Sponsor

Back
Top