>>>Now this is where we strongly differ. You can't do anything more complicated, because you need to know twenty parameters (by position or name). In ADO.net, don't you ever pass a recordset as a parameter? In old ADO you couldn't breathe without doing that. Recordset is an object.
>>
>>Once of the complaints people have had about VFP is that its classes don't all inherit from a single class that you can subclass. Everything in .Net inherits from Object.
>
>I think VFP objects inherit from Control or something like that - but the other part is the problem, we can't subclass from there. The search for the lightest base class started very early - Line was the one, IIRC.
>

VFP objects do not inherit from Control or any other common ancestor. There are a dozen or so second tier base classes, which is as low as it goes. The absence of a "mother of all classes" is the reason we had to resort to kludges like deriving from Line just because it's lightweight. I write a non-visual class to model some real world process and call it a Line? Jeez Louise.

>>>I meant "object" as an instance. Is it Microsoft redefining common words again? Last time I learned the meaning of "object" in OOP, it was "an instance of a class". Now it's a top level class... maybe the same as the abstract class in the root of the class set? Didn't mean that - I thought nobody mentions it in that sense except when explaining the whole inheritance in a lecture.
>>
>>See above.. just pass the form controls as type "object".
>
>Good. I would expect that to be the case.
>
>>>See code above. How do you implement a decorator pattern?
>>
>>See http://www.dofactory.com/Patterns/PatternDecorator.aspx
>
>Yes, that would work - as long as there are equivalents to pemstatus(), getpem() and such, it could be made to work on a generic object.

Sigh -- you are not getting this. You keep thinking action-object instead of object-action. I know you are smart enough to get away with it but you are really swimming hard against the current.