I'm just not sure I see the difference between this and simply returning This.ReadOnly. It just introduces an extra step with the property. If you're going to do that, don't bother with the 'RETURN' statement in the base control. You don't need it since you'r checking 'This.lReturn' in the child control after DoDefault() anyway.

At the same time, I'm not sure why you would need to go through all this when simply doing the check for ReadOnly in the child control is neither more coding, nor more complication. In other words, is this (in the child control):

If !This.ReadOnly
   Return !Empty(This.Value)
Endif

Really worse than using a DoDefault() to check for ReadOnly, setting a property through the base control, and then checking that in the child control?

Alan

>Thanks for the help. Do you see any pitfalls in this approach?
>
>1. Add new property to baseclass called LRETURN and set value to .NULL.
>2. Add code to GotFocus() to reset value back to .NULL.
>3. In the Valid() put the following:
>

>    IF THIS.READONLY
>        * Set lReturn so a subclass knows that a STOP occurred.
>        THIS.lReturn = .T.
>        RETURN (THIS.lReturn)
>    ENDIF
>

>
>4. Each time I subclass this control, I'll need to put the following in the Valid(), if available validation is necessary:
>

>    DODEFAULT()
>
>    IF ISNULL(THIS.lreturn)
>*!*	* Do necessary validation for this subclass such as:
>*!*	IF EMPTY(THIS.VALUE)
>*!*	    * Set lReturn so a subclass knows that a STOP occurred.
>*!*	    THIS.lreturn = .F.
>*!*	    RETURN (THIS.lreturn)
>*!*	ENDIF
>    ELSE
>        * A return value was assigned by parent class.  Use it.
>	RETURN (THIS.lReturn)
>    ENDIF
>