>Nadya,
>
>Like I suggested in my last message, you build a container with a fixed number of textboxes (your SQL line is limited in length anyway so there should be not problem if there is a maximum number of values). You put the textboxes in the container and set them to have no borders. You arrange the textboxes so their edges meet one above the other (you'll need to arrange them before you turn off their borders).
>
>You give the container a method named ValidateInput and a property named TextInputMask. In the Init event of the container you set the InputMask of each textbox to the same value as the TextInputMask property of the container. From the Valid of each textbox you call the ValidateInput method of the container.
>
>Now, nothing has been done yet about the code that does the validation, that will vary from one use to another. But you write your validation code in the ValidateInput method of the container. Each textbox can pass its value as an argument to the method and receive a T/F return from it.
>

OK, I came up with the inverse solution; tell the container (a grid in my case) what control to establish, and then use a subclassed input control that held the appropriate validation and input mask. My thinking is that the thing being entered should know how to validate itself, putting all the behavior in the control. I could just as easily pass the container a separate object that validated what it collected, but my thinking here is that the input control really is classed to the kind of thing it collects, and the input control is linked to the properties of the kind of thing it collects. It has to know how to validate itself, unless you're advocating that the control has nothing but UI masking, or that you go to a mid-tier ZipCode object to find out what it's input characteristics, and have the mid-tier object act as a server?

It seems that at some level, you pick the business object and let it specify the correct UI control? I'm not sure I want to carry all those separate low-level things. I like the idea of a candidate ZipCode knowing when it's valid.

< hanging head in shame > OK, why am I wrong?

>Now all you have to do is put the container in a form, size things to the size you want them, write the valid code in the ValidateInput method and set the TextInputMask of the container and you're done.
>
>If you want to get really fancy you could give the container a TextboxCount property and use that the add the textboxes (from a class that has the call to ValidateInput in its valid) at runtime according to the value in TextboxCount.
>

And use a member array in the container as a data source. Gee, it acts like an array; adding an entry redimensions the array. Deleting I do an ADEL() and redimension the array. I can stick the array in a parameter object on my way home, Nadya can subclass the control to put together a string from the array and create a property .Value to stick it in. No cursor necessary. Very nice; essentially a variably-sized ControlArray of textboxes. Or whatever you want to use in the control. I want scroll bars on the container.

The container inherits the knowledge of how to add an input control, you tell it what kind, how to add or remove an entry in the array, how to validate the input from the current candidate entry, and presumably what has to be done to handle navigating the array.

OK, convince me that the control shouldn't know other than generically about validating itself, rather than the control knowing it's syntax and passing up to the container the decision of accepting a syntactically-correct input to check for the context. Why does the container carry the burden of verifying that something in it is well-formed?