You don't need to write separate code at all. Make the parameter "object".

>No, I meant class. If I had to write separate code for the case when the parameter is a textbox, then the same for an editbox, another one for labels... it would take all day. Then next day I'd find a bug in one of them, and would have to repeat the fix in six others, and test all seven. I'd rather do it, you know, the OOP way, have the code in one place only.
>

Are you talking about Office automation? If so, you can use named parameters in VB.Net and they're being added in C# 4.0.

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

>
>Same if I did it on Mars - I just do it on all the objects on the whole form, because that way I don't have to know on which objects to do it, I don't have to go over 300 textboxes and other that may exist on a form, just to check which ones have font properties. That's a machine's job. And I can't do that at design time either, because some things may be added at runtime.
>
>Also, I'm not buying into the idea that I should do that for every class which may need it - too much work, I'd have to repeat these lines for each of them, for no good reason.
>


Supposedly it's slower than defining a specific type. Personally, I can't see where a couple of micro seconds will make a difference.

>What's wrong with passing objects as parameters? Are they equal but separate or vice versa, when compared with other parameter types?


Yes. ADO.Net supports both untyped and typed datasets. If it's typed or you use LINQ or even the Entity Framework, you get datatyping on the fields.

>Since I didn't have strong typing in the last 19 years, I'm quite used to avoiding that kind of error; still happens once or twice a month, and even that is not with variables, but with fields in someone's table where I guessed it wrong - and strong typing won't help me there, will it? OTOH, strong typing would literally cause a few (or dozens of) new errors, in cases where I changed my mind about a type but forgot to tell the declaration about it, or where I forgot to declare.

>
>Oh I think so much in objects that I love to toss them around as parameters...
>
>
>See code above. How do you implement a decorator pattern?

See http://www.dofactory.com/Patterns/PatternDecorator.aspx