> Ok, may be I still didn't completelly understand you idea. I was thinking you suggested to design Container with one column grid in it and 2 command buttons. Is it your idea? For grid we should be able to substitute standard textbox in column with our control (may be text, may be listbox, etc.), e.g. we need 2 additional properties for this grid: CustomClass and CustomLibName. May be these 2 properties should be container properties, to simplify the process.
>So, in Init method we should check, if we specify something in these properties and if so, use RemoveObject and NewObject methods for substitution. We should desing textbox class separately for each input, which requires validation, e.g. txtZipCodes with appropriate InputMask and Valid() method or txtStreet, etc.
>

You have a container property that specifies a control of some sort - while textbox would be the most common, it could be a combobox, or a spinner, or any of a number of controls. I'd add a property (or two if you want to be able to use NEWOBJECT() and need to be able to specify a class library - it isn't always needed) cEmbededControlClass. Names don't matter, so yours will work, too. You either set the EmbededControlClass in the property sheet when you drop the container on the fom or pass it as a parameter. I'd also allow the container to have things specifying the kind of data field (size and type) in the cursor or array, and perhaps an optional object reference to a business logic class instance.

As far as the control (textbox), yes, I feel that the control should provide the details for verifying that the content of the textbox is well-formed (right number of characters, only valid characters) but that if there's context checking (ie only allow if it doesn't duplicate another line) it should be in the container, or at least able to be delegated by the container to a business object. Jim's opinion on this is different - he put all the validation except the InputMask as the responsibility of the container.

> So, this is my understanding of your idea. Now, please, correct me, if I'm wrong.
>

This is fine; you don't have to use a Grid (I find it's easy because it fits the requirement I have and gives me the functionality I want, since I like getting back a list as a cursor). The Listbox/textbox works, although sizing automagically would take a tiny bit of figuring out if you want to extrapolate the size of the Listbox based on the size of the control used for input. The straight Collection/TextBox works. But this control isn't a function of the form - you implement it as a class in a common class library, because the behavior is a function of the control, not of the form. Drop the COntrol on the Form, and set some properties - beyond that, the form just sees it as a control.