VFP 9 Command Window doesn't restore previous commands

[dmusicant]

On this particular machine, when I restart VFP 9, the Command Window doesn't show the last several commands from the previous session. The machine runs WinXP, my others Win10 now. Is it OS related or something else?

 

[Olaf Doschke]

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.

So it can have to do with OS and system policies, but before looking into the noRecentDocHistory, check your options about where you store the FoxUser.DBF. When you have no write permission there, or you have set resource off, command window content isn't saved.

Bye, Olaf.

 

[dbMark]

Olaf's response is the most likely. Another scenario is that you had multiple VFP windows open. Only the activity in the session closed last is preserved.

 

[Olaf Doschke]

Very good point, that's a reason to consider, too, any VFP session closed replaces _commands.prg, it doesn't append new commands since load, it really replaces the _command.prg.

Bye, Olaf.

 

[Mike Lewis]

I often have multiple VFP windows open. What happens is this: When you open an instance, you will see the commands from the previous instance that was closed (at the point that it was closed). When you close multiple instances, you save the commands from the last one to be closed.

If that behaviour corresponds to what you are seeing, that would explain it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

Another thing that can cause this is when that file is read-only or you have it open. VFP can't overwrite an open file.

 

[dmusicant]

How do I determine where my foxuser.dbf resides? I don't think it's in the home() directory.

 

[Mike Lewis]

Look in Tools / Options / File Locations. Scroll down to "Resource file".

Alternatively, execute ? SET("Resource", 1)[tt][/tt] from the command window.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dmusicant]

Well, I issued this in the Command Window: ?sys(2005)

That revealed where the resource file is. The directory is Read Only. I changed that to be not Read Only, but looking again, it's Read Only. Hmm. Don't know what's up with that. Still no commands showing from previous sessions. I have only one session going, my typical usage.

 

[Mike Lewis]

Which directory is it? If it's under Program Files, or if it's under Application Data and belongs to a different user, that could possibly explain why it is read-only (and would also explain why you are seeing this in Windows 10 but not XP).

Regardless of the above comment, just try setting the directory to some other location, such as a directory directly off the root. (Do that in Tools / Options / File Locations.) You can do that on a temporary basis, just to see what happens.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

A typical location would be in AppData, in your user profile folder:

[tt]C:\USERS\YOURNTACCOUNT\APPDATA\ROAMING\MICROSOFT\VISUAL FOXPRO 9\[/tt]

And that is not read only.

Bye, Olaf.

 

[Mike Lewis]

A quick glance at various forums suggests that this is a common problem after upgrading to Windows 10 (that is, the problem of directories reverting to read-only is common, not the problem of losing the contents of the command window).

See, for example

http://answers.microsoft.com/en-us/.../4f00d3fe-82b0-4e6d-a92a-f81751aa6f51?auth=1.

The post marked "Most helpful reply" appears to offer a good solution.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dmusicant]

My foxuser.dbf is here:

D:\Documents and Settings\<User Name>\Application Data\Microsoft\Visual FoxPro 9

This machine runs XP Pro.

 

[Olaf Doschke]

Well, that is AppData on XP, yes. It shouldn't be readonly. It's the correct system folder fgor application data such as foxuser.dbf or _command.prg.
Well, typically this rather is on drive C:, but is D: your system drive? Or did you move Documents system folder?

Bye, Olaf.

 

[dmusicant]

This is a multiboot machine, it boots XP on C:, D: and G:. Currently, I'm booting to D: because the partition I've booted for years (G has some process or app running amok and using 100% CPU cycles. I'll look into that at some point or reinstall the OS.

Looking at properties for other folders on the D: drive and it looks as though everything is Read Only, however the behavior doesn't exhibit that. I edited a .txt file in one such folder and it saved fine although the folder is shown as Read Only in properties. Why, I can't guess.

Edit: Looking further, it appears that every folder, in all drives, even on my network are shown as Read Only. It seems to be an OS aberration, that's how I have to put it. Whether or not that has anything to do with the inability of VFP to restore my Command Window I do not know.

 

[Olaf Doschke]

Watch out, the read only status is a tristate checkbox, the mixed state should be a fainter light grey checkmark on XP, IIRC, on Vista and later it's a black box that looks even more prominently saying "yes" than the real checked state. If you display the column "Attributes" in the detail view of folders, do you see an R? And if entering that folder, has any file the R attribute set, really?

The main quiz question now is, do you find a file _command.prg in that folder? And is it containing your last VFP session command window content?

Bye, Olaf.

 

[dmusicant]

There is no _command.prg in that folder.

 

[dmusicant]

I found an answer. Don't know why this was necessary. A search found this page:

Link

The key specified wasn't the same on my machine [ HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoRecentDocsHistory ], however the first hit for NoRecentDocsHistory was nearly the same and I tried changing the value to 0 and this did the trick.

 

[Olaf Doschke]

Well,

saved to ... _command.prg ... unless the noRecentDocHistory system policy is enabled

Though I said

... but before looking into the noRecentDocHistory

Since no _command.prg is created, that was now the natural thing to look at.

Instead of fiddling with reg keys, you can use the policy snap-in:

https://www.microsoft.com/resources...all/proddocs/en-us/gpedit_start.mspx?mfr=true

Bye, Olaf.

 

[dmusicant]

There are something like 8 different keys referencing noRecentDocHistory. I inspected the directory structure in the registry before deciding to alter the first one I found. Fortunately, altering that key made the difference. There was no reference to Visual Foxpro, just to Explorer. I wonder what did that setting of 1 that I had to change to 0.