Form cannot be modified 1

[k2a]

A form cannot be modified any more but works correctly when starting it from Run.

When I try to Modify it, a blank window pops up and an object window also appears in it such as Form1.Init.
Because it is not shown as a scx-file no modifications are possible at the form itself.

What could cause such a behavior?

Regards
Klaus

 

[k2a]

There was just only one form involved that behaved that way as described. I will not spend any time to dig into the corrupted Foxuser record but would rather be concerned what finally cause that kind of error.

Regards
Klaus

 

[Olaf Doschke]

My assumption is, the foxuser.dbf is only really technically corrupt in the least cases. Simply wrong data inside foxuser fields causes wrong display etc. Like a huge left/top or widht/height inside a property memo of an scx would cause "corrupt".

I agree you can live without a resource file, too. But there's much more inside foxuser, than even I cared for. From the top of my head, you can influence the print preview toolbar with it, too.

As said, you'll see if some little things changed, but you may simply adjust settings when you're at it and don't lose much work and no essential stuff, and no kitten will be harmed, true. I just thought it worth mentioning before you stumble upon missing little settings.

What's causing this? The same mechanisms causing wrong data or even data corruptions in any DBF. Why should the foxuser.dbf not be harmed? As said I don't think it's caused by a header defect, maybe simply NUL chars inside a memo, whatever. If the foxuser.dbf would be broken you'd see a system error the moment you start VFP. You can turn resource file usage off, but if you're concerned about wrong records stop using databases.

Bye, Olaf.

 

[JRB-Bldr]

If the problem is coming from the VFP Foxuser Resource file, I'd recommend going back to a 'virgin' Foxuser file.

If you have a backup copy of the Foxuser files (DBF & FPT) then great, just replace the current ones with the backup copies.

If not, then you would have to modify the current file

cDBF = SYS(2005)
SET RESOURCE OFF
USE (cDBF) IN 0 EXCL
SELECT Foxuser
* --- On checking my own 'virgin' Resource table I find the last good record ---
LOCATE FOR ALLTRIM(ID) == "GTOOLBAR"
nRec = RECNO()
DELETE FOR RECNO() > nRec
PACK
USE

It may be an over-kill approach just to resolve the issue for a single VFP Form, but it should work.

With a 'virgin' Resource file, it will eliminate problems accrued over the weeks/months/years.

Good Luck,
JRB-Bldr

 

[Dan Freeman]

What's causing this? The same mechanisms causing wrong data or even data corruptions in any DBF.

And then some. FoxUser has always been a little more frisky than "just" a DBF and it hasn't improved any since the FPD days. (If anything it's gotten worse!)

I'm prone to FoxUser corruption. Some people are prone to corruption in SCX or DBF files and I can't corrupt them even if I try, but I get flaky FoxUser records almost immediately any time I turn it on.

It's cook's choice. This cook just chooses no.

 

[Olaf Doschke]

Dan, I don't remember when my foxuser.dbf last was broken. I may not make use of some IDE features, which more often render data in it useless, so maybe I'm missing good stuff.

What got corrupted more often was the foxcode.dbf, one time intellisense even caused C5 each time I typed a space in the command window. I still just repair/recreate it (intellisense manager "clean up...") and don't stop using intellisense, but maybe not using foxuser is a thing for those prone to errors in it. I can't point to a killer feature of the foxuser.dbf I won't want to miss. And maybe the worst thing about a flaky foxuser.dbf is, it's not always that obvious.

So make "delete foxuser.dbf" your top entry of a todo list, if something is flaky about anything at design time only. I'm sure many people already know this todo task very well.

I do embed a config.fpw with RESOURCE=OFF in almost all Executables, less of them also are top level forms with SCREEN=OFF, though.

Bye, Olaf.

 

[Dan Freeman]

It can bite at runtime, too.

I once inherited a vertical market app and didn't realize at first that they hadn't put RESOURCE=OFF in config.fpw. We got the MOST bizarre and flaky behavior reports from users around the country. Once I discovered it and turned it off those reports stopped completely, but all through that period we had some clients we never heard a peep out of.

There *is* a time to use it (report controls toolbar, for instance) and for those times I keep a pared down foxuser burned into the exe. Otherwise, it's off.

Just one of those things, I suppose.