>sounds pretty wierd...
>Gut reactions without any clear reason would be to test if this happens only in the init() of a control already instatianted on the form (my take on your description) or if the same behavior is seen in a class [defined with the changed init] before it is put on the form. Once it's on the form it isn't a class anymore, it is a an object instance, the term is pseudo-subclassing (as you probably know) as can be seen from the way such a method is coded in a prg - not that this should make a difference to the method not working.
>
>The other thing I'd check is if the behaviour is the same if the this.addproperty is before the dodefault()

It happened even without any dodefault(). I don't think I need the dodefault(), but I included it later, just in case.

>I won't try to recreate the behaviour: you already have a "working error", if you can reduce it to less than 80 lines of prg (change with class browser if vcx based) it is more probable that people will copy your code into an prg and play with it in the fox. The danger that some hidden complexety of your classes or VFX fwk might be "necessary" for the error will stop me from creating such a scenario from scratch, even if it might take only 20 lines - as I am lazy and not that into GUI stuff - more into the inner workings of vfp and puzzles. ;-)

I believe this will be difficult to reproduce. The form worked at first, and started to do strange things only after I changed code - completely unrelated, apparently - in some other part of the form.

Changing the AddProperty() method to the AddProperty() function solved the problem. Naomi pointed me to a thread that had a similar problems - completely different symptoms, but also caused by the AddProperty() method, also in VFP 9 / SP 2. And also solved by changing to the AddProperty() function.