RETURN DODEFAULT() always works. I believe it's a good practice if you want your subclass code to run, then the default. Don't abondon -- fix what's wrong. One could argue that all sorts of combined statements make a harder to debug, and they do; but once you trust the pattern, it's not an issue. Perhaps you have mulitple RETURNS in a procedure?

>Well, your code indeed works fine.
>
>And, I've gone back to my own code, and now I cannot get it to repeat the results I was getting last night.
>
>I *KNOW* for sure that is was not working correctly, but today I cannot replicate it.
>
>However, I still am resolved that I like my modified coding sequece anyway, so I'm still going to abandon the Return DoDefault() structure going forard.
>
>
>
>>>Some of you probably already knew this, but it caught me off guard...
>>>
>>
>>Are you sure that's what's happening? Are you sure your base class always returns a number (and doesn't have some cases where it just does a RETURN out of the code)?
>>
>>I tried it and it works fine:
>>
>>

>>o = CREATEOBJECT("TestB")
>>?o.DoSomething("")
>>
>>DEFINE CLASS TestA AS Custom
>>   FUNCTION DoSomething(tcString)
>>      RETURN 1
>>   ENDFUNC
>>ENDDEFINE
>>
>>DEFINE CLASS TestB AS TestA
>>   FUNCTION DoSomething(tcString)
>>      RETURN DODEFAULT(tcString)
>>   ENDFUNC
>>ENDDEFINE
>>