Olaf,

VFP isn't going to decompile the objcode. When it sees there is a disconnect (by whatever method it does) between the methods and objcode memo it throws up its hands and gives up in the designer. Under these circumstances it probably ought to just do a COMPILE internally and continue on.

A lot of things are also tied to some of the other reserved* fields. VFP doesn't expect or deal well with malformed manipulation of those fields.

>>I don't believe what you say is true in this case. VFP is just simply going
>>to read the methods memo field to know what to display
>
>Obviously it dowsn't.
>
>After modification of the methods memo without COMPILE CLASSLIB the class designer/editor showed the same bytes of the methods memo as before. And because of the additional line in the load event the line PROCEDURE INIT was displayed as the init event. So what bytes of the methods memo are displayed must be coded into the objcode memo...
>
>Of course, it's not of any use, I was merely trying to explain the behaviour. Of course you are right in recommending to COMPILE after making changes to the methods memo.