>>This is not data destroyed. It's a reference lost.
>
>That's true. However, for someone who's not familiar with the internal structure of VCX files (and why should they be?), it appears lost.

That's true. The method code in the child class is there, yet it's invisible. There should be some warning like "there's code for method ASDF which doesn't exist, would you like to add this method". Also, while renaming a method, there should be a warning that the method code in child classes may be stranded. Foxwish?

>>Say, would you like VFP to fill your screen with tons of warnings every time you Modify Structure - just because you had the old name of a field already mentioned in some .prg already? Or, if you issue "Do Form Whatever" in a .prg, and it can't find the whatever.scx, so it won't compile (or even save) the .prg?
>
>This isn't at all the same thing. If I change a name, I certainly expect that I have to hunt down everywhere in my code that the name is used. What I don't expect to have to do is hack the VCX. :)

Well, it's the only way I know to restore this piece of code once it got stranded. Maybe adding a method with exactly the same name would do it, I didn't try.

>>I think you're just asking too much.
>
>Not at all. Christof has presented a simple solution to this problem. The VFP programmers just weren't smart enough to think of it, apparently.

I'll have to find his message, I adore simple solutions.

>>Quite so, therefore it simply doesn't care - it assumes we know what we're doing.
>
>However, it also assumes that we know what _it's_ doing behind the scenes, in fields with names like RESERVED3. :)

If it was done consistently throughout the class/form designer, we wouldn't ever have to know what's reserved* for... but then, the rest of the world isn't perfect, either :)