Excellent points, Paul. I've also designed those types of "helper classes". You'll notice that I left myself an "out" when I said it "all depends on how you've designed your architecture" ... <g>

~~Bonnie




>>Your control should really be self-contained Marc. Once it's databound and the mask property set, it should know how to do everything it needs to do. It shouldn't have to ask up to the parent control for much of anything (I make an exception to that for rule-checking, since typically it's the Form that contains the Rules ... but again, that all depends on how you've designed your architecture. Still, rule-checking would have nothing to do with validating a mask).
>>
>
>I'd say that depends on what you're trying to accomplish (although I'd agree that it shouldn't be responsible for talking to the parent control in most cases). There are two ways of approaching this kind of thing - one way is to build in the functionality into your base class of controls. As long as you're always able to use them, everything works. The second way is to move that functionality out to an external "control" or class. That class knows how to iterate over all of the controls and attach new behavior to them. This can work really well since now you're not limited to only adding this functionality to controls that inherit from your specific subclass. You add an instance of this class once to your form and you're good to go.
>
>I use the second approach a lot more than the inheritance-based approach since it lets me easily add functionality into an application without having the mess with the inheritance hierarchy. For example, in VFP I have a control I can drop on a form that automatically sets the MaxLength property of all of my controls automatically by iterating over all of the controls and looking at the cursor/field they are bound to then looking at the underlying field width. I took this once step further and have an "Iterator" class that just iterates over all of the controls. Other classes can register themselves with this iterator and apply their own types of behaviors. Another common behavior you might want would be to set the input mask of control based on what it's bound to (which sounds like Marc's scenario). There may still be some need for a bit of configuration code to handle specific scenarios but that can usually be handled just by adding a few hook methods and/or events at key places.
>
>Having said all that, I think adding masking probably belongs at the control level while setting the actual mask can be done "from the outside" as I described.