Command History not saved if VFP closed by shutdown

[rbeitler]

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?

 

[Joe Crescenzi]

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.

 

[GTGeek88]

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.

 

[ggreen61]

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.

 

[Chriss Miller]

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

 

[rbeitler]

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.

 

[Dan Olsson]

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.

 

[TamarGranor]

Do a lot of people really leave VFP running for days at a time? I shut it every time I'm done with it.

Of course, I also shut down my development computer (which is a desktop) every night.

Tamar

 

[rbeitler]

VFP.exe is running on the server. We started having file locking issues using SMB, so I have been using VFP directly on our server that hosts our application. It is WAY faster. We also set up RemoteApp for the users, and things have been much faster for them as well.
With the RemoteApp, IT has been changing settings for screen lock etc, I think they put in a setting to automatically disconnect idle sessions after so many hours. So I think that is what killed my VFP.exe
Other scenario is leaving it open on a Friday and updates being installed over the weekend.

 

[wOOdy-Soft]

A regular server shutdown / restart will always close running programs gracefully. I.e. that's the same API call, which is triggered if you close VFP withe the closebox in upper right corner. This will also save your commandwindow to the _command.prg. Editing in the CommandWindow always happens in Memory, only when saving it will copy the newer version back to file. Unfortunately, the commandwindow has no separate "Save" enabled in the File-menu, but IMHO someone knowledgable could write an FLL which grabs that editor-handle and does a periodic saving.

Only if you have a real VFP crash (c0005 etc) or a VFP session which is not responding to the Windows-Close API call (where then Windows will just delete the task to go on with Reboot), only then VFP is not able to perform it's Shutdown task and will not be able to close its files correctly.

 

[Chriss Miller]

VFP.exe is running on the server.

If multiple users use VFP from there, only one of them has to have the habit of clearing the command window, which indirectly clears the _command.prg. Well, or only stores the commands he did from then onwards. Also if a user decides to not use a foxuser.dbf and clears the file location of the resource file that clears the command window at each start. Keep in mind this is not a file VFP appends to, at shutdown, normal or otherwise graceful, VFP just stores the command window content to the file. The help on command window also says:

Command Window (Visual FoxPro)
(_command.prg is saved...) unless the noRecentDocHistory system policy is enabled or you are not using a FoxUser resource file.

Using one vfp.exe for all users, your histories mix. So the best thing you can do is create your own foxuser.dbf and config.fpw in a user directory of yours to have your own _command.prg. Knowing it goes into the same directory as foxuser.dbf you then have your own.

 

[rbeitler]

On my PC and on the server the _command.prg and foxuser dbf are stored in user profile (C:\Users\<username>\AppData\Roaming\Microsoft\Visual FoxPro 9) so every user should be getting their own command history.

As for closing vfp.exe gracefully, I just did a test. I opened vfp IDE, entered a comment in command window, then did a reboot but left vfp open. After reboot, it only have my previous history, not the new comment. So at least for me this is the behavior.
I was hoping running this would help:

ON SHUTDOWN QUIT

But same thing, new commands were not saved if I rebooted while vfp was open.
Can someone else try restarting while vfp is running to see if they observe the same behavior?
Thanks

 

[Chriss Miller]

It works as you say, but you just lose the added commands of the last session.

This is very frustrating when you have days or weeks of command history that you need to see!

That's true, but what you describe now is not losing the history of weeks but just the commands used in the last VFP session. Or are you saying it's normal for your VFP sessions to last for weeks?

Get used to closing down your applications and shut down, I promise you your computer will work better every day, not get into lagging because of running for a long time. Even now VFP runs on a server via RemoteApp, you use a server as a client. You don't shut down that server, you shut down your client, that in turn ends RemoteApps. If I remember correctly in RemoteDesktop sessions (with or without TS) you could turn off your computer, come back, reconnect and find your server desktop session still running. That seems to have changed from what RemoteDesktop was to RemoteApps now. But the server keeps running, doesn't it? So it's now actually only server shutdowns that would cause this.

But if, as you say, other users, maybe admins do a shutdown (or Windows Update does), then the real problem is that you don't shut down your computer for weeks, nothing else.

By the way, if you look for a pattern: Every second tuesday of a month is Windows Update aka Micorsoft Patchday. So at least shut down VFP IDE and your computer on the second Monday of a month.

 

[Chriss Miller]

IMHO someone knowledgable could write an FLL which grabs that editor-handle and does a periodic saving.

Not necessary. You can save the command window content this way:

Local lcCommandHistoryDir, llSafety

lcCommandHistoryDir = Justpath(Sys(2005))
Try
   llSafety = (Set("Safety")=="ON")
   Set Safety Off
   Copy File (lcCommandHistoryDir+"\_command.prg") To (lcCommandHistoryDir+"\_command.prg.bak")
Catch
   If Empty(Sys(2005))
      Messagebox("Without configuring a resource file no command history.",64,"No Command History")
   Endif
Endtry

Show Window Command
Activate Window Command
Keyboard '{CTRL+A}'
Doevents

If Popup('ensurecopyworks')
   Deactivate Popup ensurecopyworks
Endif
Define Popup ensurecopyworks Shortcut Relative
Define Bar _MED_COPY Of ensurecopyworks Prompt "\<Copy"
Activate Popup ensurecopyworks Nowait
Doevents
Keyboard '{CTRL+C}'
Doevents
Deactivate Popup ensurecopyworks

Strtofile(_Cliptext,lcCommandHistoryDir+"\_command.prg",0)
If llSafety
   Set Safety On
EndIf

Why so complicated? Well, turns out after CTRL+A the copy menu item of the edit menu is grayed out (inactivated), so while CTRL+A did select all command window content, CTRL+C does not work to actually copy the selection into _cliptext. With the trick of defining a shortcut menu with the _MED_COPY system menu item you can trigger that with CTRL+C. It also requires all the Doevents.

Now to have that at hand at all times you could make it a menu item, add this as PRG to your project, do both or even put it into a timer, though that would disrupt working in the IDE when suddenly the command window is activated and the _cliptext changes to it.

One last important notice of caution: This is tested in my VFP IDE, if by any means any setting of VFP causes it not to work (or conditions like a closed command window - though I have Show Window, not only Activate Window) cause it to fail. Or any timing problems or flaky functionality of CTRL+C, the code does first backup _command.prg to _command.prg.bak. I ask you to verify that _command.prg is as you expect it to become before running it twice, otherwise that backup is overwritten by whatever is in the _cliptext instead of the command window content.

So in short: Please test this on your computer and inspect the effect on the _command.prg before putting this into production.
To verify it helps to add a last command or even just a comment into the command window and see if that gets into _command.prg (obviously it will only get into _command.prg.bak if you run this at least twice).

To verify _command.prg just do

Modify Command (JustPath(Sys(2005))+"\_command.prg")

One more notice: Once you verified _command.prg close that, otherwise you could get into the trap that closing the IDE saves the state of the prg you have open as a normal PRG edit window and not what's in the actual command window. Might not happen, as saving the command window should be done last and you didn't modify the verified _command.prg state, but you never know.

One idea verifying the copy step didn't fail is you check, whether _cliptext starts with _command.prg.bak and is longer than that backup. And/Or create a multi staging backup mechanism with bak1-bak9999 or whatever.