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
