Others have mentioned the possibility of various return point. There are multiple return points in the code, but I reviewed the code all Return points are properly coded to return an integer. Regardless, my new pattern would still be affected if a bool return type came back because of bad coding in the called method. I changed nothing in the baseclass code, but yet I began to get an int value back, like I was expecting.

I agree, it should have worked tghe way it was... And today it does. I'm not sure what was wrong.

I just know that I was testing for (lnReturn > 0) and lnReturn was actually a coming back as a bool, so my test code failed. The I stepped through the bebugger to see whay I was getting a bool, and I realized that I could not step into the Dodefault() code which was being called inline with a Return stament, therefore, I could not tell which part of the called code was returning the bool value. So, I assumed it was some oddity with callind DoDefault() inline with a Return statement.

I changed to the new format, then I could step into the DoDefault() code, and it passed back an int, like it should have all along.

Regardless, the mere fact that step-through debugging is affected by this inline pattern is enough to make me abandon it.







>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
>>>