>>The form/class editor relies on the compiled p-code to find the beginning and ending line of the source within the Methods memo - that's how it knows what to show in the code window - and if any of that info is out of whack, you'll get technicolor mess while editing.
>>
>>So create a copy from your backup, compile it, see how it looks. If still bad, look at the Reserved3 memo for the given object (look for record where class="clRadat") and see whether you see all the custom methods listed. The Reserved3 has a special format, it has one-character prefix (a space for methods, caron for array properties... don't remember the rest - you can try it on a test classlib), PEM name, optional semicolon followed by description, and CRLF at the end of line. You can actually use this to pull your favorite method to open up when you doubleclick the class window, by moving its line to be on the top in this memo.
>

>Although Ed R. already advised me on the COMPILE CLASSLIB thing, I completely forgot about it today. And, it helps!
>Doing it in VFP7 makes VFP5 say that it's no object file, and doing it in VFP5 makes that right again. After that, VFP7 doesn't complain, but I guess somewhere (in time) it goes wrong afterall.

This makes sense. VFP7, being newer and smarter, can run the VFP5 compiled code, while the reverse should not be true. Still, I'm not expecting it to be perfect, so I'd just recommend recompiling whenever you switch versions, just in case. The internal format of the p-code has changed in each version, and I'm actually surprised with VFP7 running 5 code off the bat. In all the previous versions, AFAIK, you had to recompile.

>BTW, I looked at your Reserved fields, but (strangely ?) there is only data at the top level class (clTbrMenLbl); Reserved2 contains a "3" only and Reserved3 only lists the custom properties and methods (including their description as put at creation).

That's what it's for. That's how VFP knows the child class has some of the PEMs of its own.