Hi bonnie,

>I'm not quite sure why you don't like Rod's idea of using an Interface. That is the way I would do it too. The Interface would have the SetFocusAtAdd property. For any control that you would like to be able to set focus to, your base class for that control would implement that Interface. You'd check the controls in your form to see if they implement that Interface and to see if the property has been set to true. Seems perfectly OO-ish to me.
>

>if (oObject is ISetFocus && ((ISetFocus)oObject).SetFocusAtAdd == true)
>  oObject.Focus();
>

I missed that part of interfaces, I thought Rod was talking about getting the exact type of the object. I can see how this might work. However, I have some doubts in this...

Most of my controls are very specialized controls with lots of properties and methods that aid certain framework functionality, not just one like "SetfocusAtAdd". Using your strategy would mean that I have to explicitly add many interfaces (since I just want to keep the granularity on functionality on the different controls) on each control class. The idea that whenever I'm going to hunt into a certain object in a tree (like a form) for what ever reason I have to make sure that the interfaces are added to the object I'm hunting for is somewhat odd to me.

It bothers me that I appearantly am not able to question any random object for its members and actually use those members if they exist. Like:

IF PEMSTATUS(oObject,"SetFocusAtAdd") AND oObject.SetFocusAtAdd

and to workarround that limitation I have to use interfaces for every method or property I have to question.

But then I think this might be closest as possible to the VFP code.

Thanks,

Walter,