Can't change fields in browse mode

[radiorog]

All of a sudden, my tables don't allow typing text into fields in Browse mode. If I type in a letter or number, it shows ... but as soon as I type another character or space, the first one disappears. And so on. The weird thing is, some text fields seem to work okay while others don't ... and same with numeric fields. Etc. Etc.

Same thing whether I'm doing it in VFP8 or FVP9.

Any ideas what's going wrong? And how I can fix it?

Many thanks.

Radiorog

 

[Olaf Doschke]

What you describe would happen in a table with only one c(1) field, if there are two fields, that would not work anymore, as typing the character will fill it in and tab to the next field. It also onviously doesn't happen on readonly tables. Buffering wouldn't cause that but only fail to commit the buffer, if single records are locked by another user.

No idea what could happen here, but can you share the structure of the table you browse and how you browse it? As you say "Browse mode" I get reminded of having a browse window in Edit vs Browse mode, which diesn't change edit capabilities, though. But you might even mean something else.

Bye, Olaf.

 

[radiorog]

Image of DBF structure attached.

By "browse mode", I mean using the Browse command in the Command window to view the table. I use both Browse and Browse Last. The problem exists in both.

FWIW, it also occurs whether indexes are used or not. Just Using the table by itself, it still happens.

I also checked the properties of the DBF file, and it's not read-only.

Thanks for any help you can provide, or even just more things to check.

Radiorog

 

[radiorog]

BtW, I'n running Windows 10 v. 1709, if that's any help.

Radiorog

 

[Olaf Doschke]

What's interesting about the table designer is a Memo with 10 bytes. That normally is 4 bytes only, for a 32bit pointer into the fpt file. Looks like there is some defect or it's not a native VFP table.

Well, and instead of just trying with BROWSE and BROWSE LAST you could try to eliminate any influence of foxser.dbf by moving it from it's current path to an unrelated directory (while VFP is shut down), so FoxPro creates an empty new foxuser.dbf at its next start. You can put the saved foxuser.dbf back later and try to just remove the records causing this misbehavior, if that fixes it.

But maybe it just is related to the unusual Memo field width.

PS: I see, that you can have 10-byte memo fields if you create a cursor and COPY TO some.dbf fox2x, creating a legacy FoxPro DBF. Whats true is that this isn't Visual Foxpro DBF, but it could be a legacy FoxPro DBF, nonetheless.

Bye, Olaf.

 

[Dan Freeman]

I agree with Olaf about that fishy memo field and about Foxuser.

BROWSE LAST is actually the default if you use plain BROWSE. For grins, try BROWSE NORMAL.

 

[Olaf Doschke]

Yes, I forgot about BROWSE NORMAL, but I can't imagine any setting saved in foxuser.dbf that would limit editing of char fields to one char and all the other odd behavior.

Bye, Olaf.

 

[Dan Freeman]

Hey, we've all seen Foxuser cause weirder stuff.

 

[radiorog]

Well, I found the culprit. For those who might experience this same problem, here's my solution.

Right before VFP started acting up, I had installed a password manager called Sticky Password. (Pretty good app, by the way.) Anyway, since that was the last major change to my system before VFP started misbehaving, I turned it off and rebooted. VFP then worked perfectly. So Sticky Password obviously was tromping on some Windows setting or memory address that VFP wanted to use also. Fortunately, Sticky Password has a setting to ignore certain other apps. I set it to ignore VFP, and now they play nice together.

On the memo field length issue. Haven't a clue why it's set to 10 bytes. But the table was originally created in FoxPro for DOS. Maybe that's the reason? Anyway, it's been working fine in VFP8, so guess I won't monkey with it. Unless one of the gurus here thinks I should change it.

Many thanks for all your help and advice!

Radiorog

 

[Olaf Doschke]

No, I already found out it's normal for legacy DBFs to have such "extra long" Memo fields.

Bye, Olaf.