Ed,

>>>>You could create a container class with a fixed number of textboxes that have their borders turned off and it would look exactly like the editbox without scrollbars in it but each textbox would fire its valid with one discrete value in it for you to check. If all the textobxes needed the same validation you could easily add a method to the container and have each textbox call teh containers method from its own valid.
>>>
>>>
>>>Or, maybe a combination of a textbox and a listbox - so whatever you type in the textbox gets validated in it, and goes to the listbox. I've seen this sort of interface in several places, and it's not that bad at all. In the listbox's rightclick you may have the 'remove' method, or a 'remove selected' button below the listbox.
>>>
>>>It's been said, if it can't be done in at least three ways...
>>
>> You're right. You know, the more I think about these approaches, the more I like them. It's honestly... After Ed wrote his letter, explaining me details about grid class, I was thinking about it. I thought at night and it became clear for me how to define such class in the morning. I have this code in my mind using NewObject method to substitute regular textbox with my class textbox in Init method. I also need to have property CursorName and create cursor in Init method. I may also use logical property CloseCursor, to close it explicitly in Grid Destroy method, etc. BTW, I already made these changes for btcc_multilist class, so, I may do it in parent class instead, because code is the same for both grid and listbox.
>>
>
>You aren't thinking far enough ahead - this sort of data entry control (a container object, that can hold n occurences of an instance of another control) is a pattern that recurs constantly. This should go into a standard toolkit

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.

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


for you so that you simply drag the control to a form, set a few properties, and use the same idea over and over again for almost anything that fits this model of data collection.
>
>> I also like now the idea of textbox+listbox, which was originally suggested by Ken Weber. BTW, I even think, that this approach and grid approach don't require necessarily command buttons. We can place code in KeyPress method, which would handle this. But may be command buttons're just fine, I haven't decided yet.
>>
>
>Whatever you like; the buttons themselves wouldn't do any more than make a call to the container's custom AddItem() and DeleteItem() methods. The stuff that gets handled by the container (from my POV) is list navigation and context validation of well-formed values returned by the input control in the container.

Right, I understand this.