>>Could anyone shed a light on this one please :
>>
>>We have two VCX files. Say Main and Sub. Main contains top level class definitions, and Sub contains definitions based on classes in Main.
>>As I found today, in one case a definition in Main depends on a definition in Sub that depends on a definition in Main. This was done by coincidence, and via drag and drop. Here is the structure :
>>

>>clTbrMenLbl        (in Main)
>>  clRaDat1         (from Sub) Note the "1" and the "class" being clRaDat actually.
>>    LblText        (from originally Main BUT now from clRaDat in Sub)
>>    LbLTextULine   (new object added to clRadat1 in this clTbrMenu class)
>>

>>
>>To be clear : the clRadat class from Sub was dragged onto cltbrMenLbl in Main.
>>
>>I broke my brains on this one when I encountered it at browsing the VCXes. All looks right but :
>>
>>This happens to be the exact place where the VCX gets "corrupted" when loading it into VFP7 and adjusting a method from clRaDat1 (see the other thread "Compatibility report 5-7" thread #697466). But what's corrupted here ?
>>It's not the memo (Methods field) because I just can see it, while VFP7 and VFP5 won't show the memo's from ClRadat1 anymore, except for the Init method (being the first PROC in the Methods Memo).
>>
>>Please note that I already installed W2K SP3 over SP1, so it can't be that anymore. In addition to the status of a few days ago - "Main.VCX is not an object file" at editing the clTbrMenLbl class from VFP5 - today VFP5 could load it again. But ... also exactly the same started to happen as the few days ago : an adjustment from VFP7 to a clRadat1 method, just wouldn't come through.
>>
>>Notes : I am sure nothing was edited from VFP5 (just try-and-look), and the running app can't find the methods anymore either (it's MouseMoves, MouseUp, MouseDown so all keeps on running without real error).
>
>Did you recompile when switching versions? What compiling does with methods, is to keep track (among other things) of beginning and ending line numbers of each method in the memo. However, it's not parsing the Methods memo to find the "Procedure" and "Function" keywords, it's first parsing the Reserved3 (or 4, always forget) to find their names. So first thing to do, when there's a problem when switching versions, is to recompile (compile form, compile classlib, whichever applies) and then to look if there's still something wrong.
>
>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.

Dragan,

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.

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).
Reserved1 tells "Class" and Reserved6 tells "Pixels" (opposed to Foxels I guess). That's really all.

But never mind, I believe you in that what you told will be somewhere.

Thanks Dragan.