The globality of FOXUSER.DBF. 3

[dkean4]

I have been hesitating concerning how the FOXUSER.DBF file should be used. Should each Project have a FOXUSER.DBF file set in its own directory, or can we use the FOXUSER.DBF file within its Installation directory like:

From the Environment Manager I notice that you can choose any location you desire. I suspect that I have an issue with the FoxUser.DBF file so if I do not need to sprinkle it into each Project's directory, I may as well put a good copy into the root directory. Any tip would be appreciated.

Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[Mike Lewis]

Dennis,

The main thing to keep in mind is that FOXUSER is essentially a tool for the development environment. Although it is possible to put it to use at run time, I think it would be quite unusual to do so.

On that basis, I have never considered having multiple versions of the file. My present setup has many projects. But it only has one development environment.

Other people might disagree.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

To add to Mike's thought:

IF every project would need a separate foxuser.dbf, then how would you have two projects open at the same time with clashing foxuser files. I see it as one "settings and more" file for the whole IDE and as someone suggested in your other thread, once you have everything as you want it it's a good idea to make a backup you can go back to whenever the foxuser.dbf gets corrupt, and it didn't happen as much to me (good luck, maybe) as I see it reported by other developers or even users.

It doesn't store all the settings, some are also registry stored and so by deleting the foxuser.dbf and making VFP create a new one you don't lose everything.

Your phenomenon is nothing I ever saw, so your observation that it is a bad record or even corruption of PJX might be a good explanation, but I don't think a PJX stored anything about methods, as they are stored in VCXes or PRGs including which tells which of them has code and will be listed bold (usually). And I don't think it even depends on one bit of any file or registry entry, whether bold/normal is inversed, why should that even be flexible, the help clearly says bold methods have code, always. So I rather would look into font or windows issues than any VFP files.

Chriss

 

[Dan Olsson]

IMHO one should NEVER install VFP in Program Files, that's just asking for trouble.
I have it in D:\Program\VFP7 and D:\Program\VFP9 respective. That way if I reinstall the OS on C: or I switch to another computer I can just copy the entire directory to a new place.
Haven't reinstalled VFP in at least 20 years

 

[dkean4]

Chriss,

You said: "So I rather would look into font or windows issues than any VFP files."

Some of my new projects are causing this. It is not universal, Chriss. Like I said before, Most of my old projects are just fine with the Bold font signaling code. It is happening in the PROJECT_ABC.PJX files.

Nevertheless, thank you all for making me think. You guys all rock!

Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[dkean4]

To Everyone who participated/followed this thread

I finally figured out the Highlighting issue. It has everything to do with the FOXUSER.DBF file. In the Environment Manager, I unified 2 of the Projects to refer to the same FOXUSER.DBF file and that source project is the one that does not have the problem with highlighting. The result is that the highlights of the coded Methods are now working correctly on the faulty project as well. That probably took place because I messed with the FOXUSER.DBF file on one project and later propagated it to other projects. I wanted to see the FOXUSER.DBF's extent of influence

I'm now happy like a pig in mud!

Thank you all for your contributions! As always, Tek-Tips rocks.



Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[Mike Lewis]

Well done in figuring it out, Dennis. I must say that this is a most unusual situation. I don't recall ever coming across it before. For me, it justifies the policy of only ever having a single Foxuser file across all my development work (and also not to use the file in run-time systems, but that's another story).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

I still wonder how.

I know it's impossible to store breakpoint line numbers in PRGs as they are simply ANSI (text) files and there are no extra bytes for any information like that, so breakpoints in PRGs are persisted in the PJX data. Anyway, like Mike I'm fine that you finally found it and I take the same lesson from it. Just use one foxuser.dbf. The idea of a backup, when you have a good situation is still also not wrong, so when anything goes wrong with the foxuser, you don't need to start from scratch but from a backup.

Chriss

 

[TamarGranor]

@Chriss, I'm pretty sure breakpoints are stored in FoxUser, not PJX files.

Tamar

 

[dkean4]

Mike
There are things that I still take for granted. I have done wild things in my days, but there are many things that I should have learned long ago and still have a hazy insight. This one was a doozy.

I was trying to make sure that one project did not mess up another. I made tools to create buttons that look cool and special comboboxes that have a glassy look, grid helpers to make them better looking than VFP, and being too lazy to compile them I used two open projects concurrently. While I had problems, I still was able to accomplish quick fixes. Finally, I learned the lesson. Compile the tools before using them.

Dennis




Dennis Kean

Simplicity is the extreme degree of sophistication.
Leonardo da Vinci

 

[TamarGranor]

You're welcome. I use it pretty much every day myself, too.

Tamar