Visual Foxpro 9 Command Window Disappeared 4

[Peyton Todd]

After VFP 9 has been working for years on this Win 7 computer, now suddenly the Command Window has disappeared. Any ideas on how I can get it back?

I've tried Ctrl-F2, which is supposed to turn it on/off, but no luck. And I've been unable to repair it via the option in the Control Panel since it tells me it cannot reach Drive E, where it claims it was installed from. Maybe that's true if it was installed from a DVD on drive E back when this computer still had a DVD player, which it no longer does since I had to have it removed for there to be a slot for a second hard drive. And I no longer have the original DVD (or CD?) anyway.

I've been told one way to fix it might be to run "c:\Program Files (x86)\Microsoft Visual Foxpro 9\vfp9.exe /REGSERVER" from the text box that comes up when you click the 'Start' Windows icon at the left hand corner of the screen, but that seems not to work. It says it can't find it. I'm getting old, so prone to forget things, but didn't it use to be possible to just type in the name of a program in that box to run it?

Or is it off the edge of the screen somehow? For years when I would open VFP9, the Command window would to often appear with only its title visible in the very bottom right hand corner, but even when I dock the task bar elsewhere, no Command window appears to have been hiding behind it.

I also can't find any Command Window object like there's a _SCREEN object where one could tell it to move back onto the screen. That actually worked recently when, on another computer, the Main VFP9 window had started to not show up. It was fixed by the command _SCREEN.Move(0,0,400,400)!

Thanks in advance for your help.

P.S. I just remembered one can go to DOS via CMD at the run box. So I tried the REGSERVER method from there. Which I tried, but was told I have to be an administrator. So I opened Accessories and chose to get to the DOS prompt as an administrator. It accepted the /REGSERVER parameter but nothing happened. I assumed maybe it did the desired work without informing me, so I tried again without the parameter, and yes it opened VFP9 but that did not fix the problem.

 

[Mike Lewis]

First, forget about REGSRVR. All that does is to re-establish certain registry entries, such as file associations. It has nothing to do with the position of windows.

Details of the system windows, which include the command window, are stored in the Foxuser files. So your best bet would be to look for all the FOXUSER.DBF and FOXUSER.FPT files on your computer, and delete them. Don't worry. You won't lose any important information. But all your system windows will return to their default positions.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Koen Piller]

Peyton,
Try first:
in VFP Menu: Windows ->Arrange All
if that does not show your command window.
than delete your Foxuser.dbf -> restart VFP9
That should bring it back
Regards,
Koen

 

[Olaf Doschke]

Fortunately, CTRl+F2 does not toggle the window on/off, it lets the window appear, so you don't have to guess or be lucky for it to be available. And so you can type in a command blindly. Because after you toggled it visible focus will be there, at the least after you restart VFP. Then CTRL+A and DEL will clear it and then type in [tt]MOVE WINDOW 'COMMAND' TO 0,0[ENTER][/tt].

Also, you can position the _screen within registry keys. As Mike said the vfp9.exe /regsvr call will not help with that, but regedit, HKEY_CURRENT_USER\Software\Microsoft\VisualFoxPro\9.0\Desktop.

Then start the debugger window and there you can also execute commands by writing _vfp.docmd("your command") as a new watch expression into the watch window, ie [tt]_vfp.docmd("MOVE WINDOW 'COMMAND' TO 0,0")[/tt]

I recently also wrote about such options and why you pick them instead of going for a reinstall. See thread184-1801815.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

Oh, and by the way,

if you have the _screen visible, Koens recommendation of "Arrange All" is worth gold, the only prerequisite is you have to untick "Dockable" if it's ticked because arranging windows is only done with non-dockable windows and the "Dockable" menu item toggles that for any dockable window. In case some are docked each untick undocks one of them and so it may need multiple times unticking until it's really unticked and no window is dockable.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Peyton Todd]

Thank you thank you thank you! Getting rid of FOXUSER.DBF really worked!

What's weird:

1. Yesterday a search I did for FOXUSER took a very long time, and the only one it turned up was the one it found on an automatic backup external drive.

2. After opening VFP this morning, a search for FOXUSER did find the file (dated appropriately for today at 9 am), but the only thing it said for WINDCOMM was the mere word "DEFAULT".

Also, forgot to mention: I tried the solution of cascading and arranging the windows via the menu option and it had no effect. I don't know why.

 

[Mike Lewis]

this morning, a search for FOXUSER did find the file (dated appropriately for today at 9 am), but the only thing it said for WINDCOMM was the mere word "DEFAULT".

That's right. Given that you had deleted the file, the next time you launched VFP it would have recreated it, with defaults for the various window positions and sizes. That's what you were seeing at 09:00 this morning.

(By the way, the record you should have looked for has the ID WINDCMD, not WINCOMM.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

It's always a bit of a loss when you delete foxuser and you'll only realize this case after case some window needs adjusting, you resize columns in browse of certain dbfs, etc.
Sys(2005) tells you where foxuser.dbf is. It's obviously hard to see it without being able to use the command window, but that's also something the watch window of the debugger can show you.

Bye, Olaf.



Olaf Doschke Software Engineering

https://www.doschke.name

 

[Mike Lewis]

And also remember that if you want to open Foxuser from within VFP (which is normally the case), you have to SET RESOURCE OFF, otherwise you get a "File is in use" error.

Alternatively, come out of VFP, then navigate to the file in Windows Explorer and double-click on it. That will open the file in a new VFP session.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

You can also simply say USE SYS(2005) AGAIN.

And all I'm saying overall is in the least number of cases the foxuer.dbf is corrupt, something just is unfortunate like an off-screen command window.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Peyton Todd]

It may be that a corrupt FOXUSER file was indeed the problem. I say this because I neglected to mention EARLIER that the FOXUSER file that I found had been created after opening VFP this morning at 9 am (although none was there the night before except the one placed automatically on an external backup drive) was NOT what solved the problem since the problem was still there even with that new FOXUSER file. It was only when I deleted THAT file and then re-lauched VFP (thus making yet another FOXUSER file) that the COMMAND window became visible again.

This worries me since it suggests that whatever caused the corruption of the FOXUSER file in the first place is still there waiting to work its woe again.
Peyton

P.S. Quick note to Mike Lewis: it was indeed WINDCMD, not WINCOMM that I checked and found nothing but the word DEFAULT. I just didn't remember the its exact name and just guessed it might be WINCOMM!

 

[Olaf Doschke]

Well, you look into the 'Name Memo, the position and other data about WINDCMD is in the data memo. No, the foxuser.dbf was not corrupt, it just has an off-display position in the binary data.

You can easily rename the foxuser and create a new text files rename it foxuser.dbf to simulate a corrupt foxuser and when you start VFP then it'll error with this message:

Wrong or unfortunate data is not a corruption. As the data is stored in a binary format, you'll also not be able to edit the window position within the records data memo, that would require to know its composition. You can clearly see the font used for the window is part of this and can be read, but the other things seem like garbage, but are just binary data.

There are several ways to get the window back to a visible position without deleting all other sometimes valuable data you have in there and just now don'Ät realize is missing. Most likely nothing world shattering, but as I said VFP stores information about how you positioned windows, not only the IDE windows but also browse windows and others, and many more things. Other options are stored in the registry, so they are not lost. Yoi'll perhaps notice from time time, that you'll need to fiddle with something you thought you'd set before.

But I can remove your fear that the evil lurks and will cause the same trouble again. Well, the foxuser may one day get really corrupt, but then you'll see this at start of VFP and it simply creates a new one itself, without your intervention. It's just a well known fix because there are many things inside it that could cause trouble not only due to file corruption but due to the data in it not being easily editable, when it's broken.

In this case, really, we're only talking about a high LEFT or TOP position that puts the command window into a second display you perhaps had in a previous session or really just one byte of the data memo flipped and caused such a too high value. And there are several ways instead of deleting or editing foxuer to fix it. Just remember the ability of the debuggers watch window. It's also really helpful when the command window is not visible during debugging. when single stepüomg through code.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Peyton Todd]

Thanks for reassuring me, Olaf, but I still have three issues.

First, I would like to know the difference between corruption and just a byte getting flipped. Merely the magnitude of the change? I'm accustomed to thinking of corruption of a file as due to some external cause as opposed to a mistake on my part. Something like a hardware glitch, or at any rate something as random as cosmic rays. Is that not right?

Second, while the problem may have been due to something I did (like drag the Command window too far toward the edge of the screen - but is that even possible?), I still can't help wondering if something else might be wrong. As I pointed out, the FOXUSER file that got built automatically at 9 am (since there was none there at the time except the one on an automatic backup external disk drive) did not cause the Command window to reappear. It was only when I deleted that one and had VFP create yet another one that the Command window suddenly reappeared.

Three, if it's all binary, then why was I able to read the value of WINDCMD on one occasion as the full word 'DEFAULT'?

Thanks,
Peyton

 

[Koen Piller]

Peyton,
I believe you are mixing things.
Foxuser.dbf has 7 fields: Type, ID, Name,Readonly,ckVal,Data, Updaten.
From these fields Name and Data are memo fields which store bidata, you may not be able to read bindata under normal circumstances, if you can than something is wrong.
In the field ID the name of the object is stored, like e.g. WINDCMD for, I must presume the WindowCommand and also e.g. WINLAYOUTS plus I don't know howmany objects.
You can have, and most developpers have, different FoxUser.DBF. Every .DBf does not contain all the same objects in the field Name.
If you have a utility like "Everything" on your HD, please search for Foxuser.DBF, I find around 60 (!) on my HD.
The file will be created by VFP if it can't find one on starting. This goes without any notification just like that.
Now there are circumstances where Foxuser gets disrupted, corrupt or whatever this can result in the situation where you can't find/see e.g. the commandwindow anymore. Nothing to worry, just delete the foxuser.dbf, restart ( a new one will be made ) and you are fine again.
If you encounter a very frequent corruption of your Foxuser.dbf (what is frequent?) I advise you to re-install VFP9, upgrade to VFP9SP2 and you should be fine.
In brief, do not worry about this.
Regards,
Koen

 

[Olaf Doschke]

Before I go into the details: You can simply put this away as a one-time case and learn from it as all others do: Deleting the foxuser often helps as a new file is created with working defaults. You don't lose any world-shattering important values or source code or project settings etc.

-------------------

My major point in all this discussion I started is just twofold:
1) a reinstall is NOT the best way to solve any VFP IDE complication.
2) Even a deletion of foxuser isn'r necessary most of the time. It is just in part more convenient as you can put away your problem faster than by needing to analyze it in detail. As already said nothin world-shattering is lost, but a lot of unimportant records also is important.

Why is this so important for me? I am a bit sick of the reputation that this causes, of VFP corrupting files. It's not the case, specifically in the off-screen command window. No matter how the wrong position is stored, it's easily solved, your file is not faulty or prone to become faulty again, soon. That can sometimes be the case with much more complex index corruptions that can be healed partly with reindex and still leave a crystallization point for next index corruption, a series of index corruptions happened to me often enough and it always stops when deleting and restarting a CDX from scratch.

A reinstallation will often not work, because it does not change the foxuser, which is stored outside of program files in your user profile. Another reason why the foxuser deletion often is recommended, as it helps even better. That's also why I recommend to first uninstall in the other thread I mentioned, an uninstall does more tidy up, more file removals, maybe even removes your foxuser (I haven't tested) as it was already part of the installation process when you installed using your windows account. Whereas a reinstall only looks for files older than it installs, overwrites main EXE and DLLs, but it's not a cleanup operation. A reinstall of Office actually puts it into repair mode, but we don't have that in the VFP setup. That's a major issue.

It gets me almost mad this is the first thing that comes up in people's minds as "the solution" to everything. It's a tedious long-running process, though in case of VFP it is done in under 10 minutes. But, come on, there are simpler solutions. If you momentarily don't see the mouse pointer, do you restart windows or do you jiggle your mouse a bit?

I know you felt helpless about the IDE situation, but you could at least get the idea to try typing blindly. Start with something that's easy to type blindly like ? 1 and if ENTER brings up 1 on the screen you know the command window is there and still executes your commands. Is that really already too much asked to try instead of feeling powerless? It seems to me.

Admitted, that's a frightening situation at first, but you're not the worst in all of this, you at least do backups. The backed up foxuser.dbf, is that perhaps healthy? Or is it a backup of "forensics" about a previous foxuser problem?

As I do this professionally I usually have more than one computer not only to cover the home vs. mobile use case but at the same time as backup of the whole development system. That can also help, of course. Let's see if I have an anecdote about this. Yes: You may know and have worked in shared offices. I worked there with a notebook, too. Easy to transport home, but also one day we had a power outage. Happens more often in other countries, but it also happens in Germany. In that case, it wasn't a problem of some power plant but just a fuse in some level of the building. And my notebook just kept going by its battery.

-------------------

As you seem to be deeply worried:

Actual problems in the single-user usage of VFP, especially of the VFP IDE lead to lesser and lesser problems, the better Windows itself became. In Win95 I had lots of RAM problems and OS crashes, nowadays I simply have GB RAM instead of a few MB. System crashes themselves have gone down, the NTFS file system instead of FAT is much more stable, everything has become more stable and so has VFP. I could also leave it as it is because you guys are already punishing yourself with a reinstall that does not help.

If you don't really care, you at least have learned now where to find foxuser.dbf, the real essential one (and how bad Windows Explorer file search is) and so you have a fast route for getting the IDE back to normal in most any case without needing any special skills to get something back to normal yourself. Though it is possible to add menu items that stay persitent and one could have the commands to move the command window to 0,0 and make it visible. It would just be a defense against that specific problem, of course.

Just as an anecdote: I also had the command window off-screen one time and that was before I knew about the helpful stuff about the screen position in the registry and how the watch window can work as command window etc. I had used VFP with a docked notebook using 3 displays. Then next time I started with just the notebook. And when the command window is on display 3 it stays there, VFP does not readjust when the position is too far right, it just takes the position stored in the DATA memo for granted. I can't help you if that's not funny enough to you. At least I got the idea myself, to re-dock the notebook and then move the command window to Display 1.

I am already quite sure you will say that is not the case for you, as you don't use a notebook with varying desktop sizes on varying display numbers and there is no further developer doing so. But is VFP installed on a share? Then the foxuser also is shared, maybe. There are surely reasons I can't even think of, that make VFPs end of IDE session store a wrong coordinate in the DATA memo, but you can be sure it happens rarely, it does not repeat often just because it happened once. And even if you'd suspect a hard drive sector error, now having created a new file that record is on a new sector for sure. HDDs and SSDs will not use the same sector again before having used others. Recycled files, even when you empty the Windows recycle bin, don't let the file system reuse these gap sectors first before using new sectors, whenever it's unclear how long a file is, the file system will not rely on such gaps being sufficient, it cares for not fragmenting files, so it usually takes from the contingent of previously unused sectors all continuously empty.

Whether you need to worry about a hard drive is something you should know yourself, you know how old your computer is or how new. There also are tools that tell you, google S.M.A.R.T monitoring or more generally, ask a hardware guy about hard drive degrading and warranty times, life cycles, etc.



And now to your questions, if you still like to know more details...

---------------------------

First:

Corruption: VFP detects a corruption when the meta-data within the DBF header doesn't work out with the rest of the file, for example with the file size. Most often the RecCount stored in the header does not match the file size you'd expect from that count. Unless the byte flip occurs in the header in an essential place like this count, a file corruption, therefore, isn't caused by a byte flip. The usual cause why the reccount is off by one is two writes are happening in reverse order, they both prolong the file by say 1 record each, also both increment the count by 1, but the lower count of the first operation is stored last.

Byte flip: Well, let's talk of any wrong data stored somewhere. In the case of x/y positions, these are 2 integers, both 4 bytes long. And there are no wrong values for integers, any 4 bytes make up a valid integer. There is no byte or bit combination that is detectable as wrong. This differs from data type to data type. In dates no 32nd day is valid, so a date stored in string format YYYMMDD can only have valid DD values in the range of 01 to 31.

So now you may say that a coordinate higher than screen width or height is enough of a sign of data corruption that VFP should correct that, but indeed even negative coordinates are valid in a setup of multiple displays, where the secondary (or further) display is oriented left of and/or on top of the main display with the (0,0) origin coordinate.

So no wrong command window position would let VFP repair that. And even if both things are happening in a DBF only in the rarest of cases it's a sign of hardware fault. The explanation of how the RecCount can be off by 1 should make clear that this isn't caused by a bit on some hard drive sector not being magnetizable the right way anymore. Also even when both things happen this is not a file with a missing sector or anything you would call a corrupt file on the file system level. Both things are simply wrong byte values within an otherwise technically healthy file. It's still a byte array, all bytes still have 8 bits, and bits all are still either 0 or 1 and never 0.5, or 2, or -3.

You never said you had the error message I posted, so you never had a really corrupt foxuer.dbf

The only reason the deletion of the foxuser table is so often recommended is, a new foxuser puts things back to normal. I have noticed you said this was the case and still didn't solve your problem. Well, from the forensic data available to us aka what you said tells me you didnÄt delete right foxuer.dbf at first. Only in the second attempt. I also noticed you found a new file date. Any new start of FoxPro updates it and every end of VFP, any action that changes data because it is the last modified date and not the creation date. It's so bloody clear because VFP will never create a new foxuer.dbf with a command window record with the data of the previous file or anything like that. And VFP never simply writes out a new foxuser without letting you know and override or allow it.

Second:

Well, I think I already covered what I think happened, there's nothing to worry about unless you have an old system. You should know that computers don't degrade like fading away photos on paper, bits and then bytes and then more flips from good to bad, there is only slightly gradual aging since faulty sectors in SSDs can be replaced and I mentioned S.M.A.R.T. monitoring already. I just fear you didn't back up the foxuser, so you can't even find out where the position of the command windows was in that foxuser and if it was just wrong with one bit flip or whether it was totally off or even the complete record was missing or whatever. Like ever so often, there is nothing left to learn more from the forensic data, it's like the cleaning of the artwork bathtub of Joseph Beuys.

Third:

The simplest question, as I already said so before you posted that. Might have crossed and you already noticed, default is a word I also found, in the NAME memo, but the data about settings of the command window is in the DATA memo. I don't know what default means as NAME, maybe that VFP takes the default name "command" for the command window. I actually don't care, I maintain the command window position by MOVE WINDOW, not by fiddling with foxuser data. Other data about other things is quite human-readable and easier to edit than such binary data, but foxuser is not intended to be maintained by a user throughout all the settings and data it maintains, it's there for FoxPro to maintain user-specific settings. And that's also why it's stored in your profile and not in the installation directory.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name