Hi Bhavbhuti,

>Right now it is not required but what if there is code in such a method and >still has to be complimeted by dodefault() in the subclass?

>I had previously put in dodefault() in the subclass and populated the code >now becuase of dodefault() (which I will remove) the assert always fires.

This is my "quick'n'dirty"-approach. It works in about 90%.
Also, I usually try to diversify my methods into groups:
may never be changed / overwritten
can be overwritten, but dodefault needs to be called
should be overwritten and dodefault shouldn't be called.

and guessed, that your question was meant for a method of group 3.

A more elaborate approach if dodefault is necessary is to save in the base method plus the calling chain of dodefaults from the first method call in an array. Most of the times only neccessary if I made a blunder and nothing to be doing on a permanent basis.

Of course any other scheme setting some properties on the class works as well, but is in my eyes a burden in the long time, if not used sparingly.

Better IMHO are methods that change a REF-parameter or give back
specific information in the return. One dirty trick if the method is supposed to be a specific datatype (mostly .t. or .f.) is to return .null. in the base method: but then you need to remember to always check with isnull() as well - therefore my preference for the dirty way of doing things.

>Also I put in Init() of my class this.replaceid() (the method name) so that >the assert will fire at the very start, so I don't have to enter the cbo to >findout it is not populated.
Good Idea. One thing though: I try to keep events as clean as possible, calling delegate methods from there. If there is a chance, that other methods need to be checked, create a chk_init() and put this.replaceid() in there. Since init only fires once for each object, performance penalty is nearly null.

HTH

thomas