>Ed,
>
> Did you see my other example? I mean, name search, when each text value could be different lenght? How will you operate in this case?
>Again, how will you search this:
>Rauh
>Pikman
>More
>etc.???????????? Different lenght of text values, any symbols allowed, including @$#!
>

How would I do it? If I were looking for a variable number of variable-length discrete strings, make a cursor with a big character field, use it as the recordsource of a grid, and when I create the grid, drop an appropriate textbox into the column with a subclass included the input masking and validation needed per line, and put on an Add and Delete button for the cursor. Any time I wanted to do the same thing for something with a different size, different validation, etc, I change 1 thing - the subclassed textbox telling me what's legal for the class, and something to populate a parameter object to return with the values, probably in an array property. Same basic class handles all situtations - fixed length, variable length, different input templates, formatting requirements, everything that needs this functionality uses the same class, and pass in the textbox subclass for this instance when it starts up. Makes its own sauce.

Each line needs to know how to validate itself - and that's what gets put in the textbox that handles the instance of data. A Grid is a convenient collection of indeterminate size, that I can query, plop into an array, build a string from, or whatever. Regardless of your experience with using INLIST(), I use a lot of WHERE something IN (SQL subquery) because it's fast, deals with situations where you have lots of choices without worrying about variables or memory, can be preserved(!) easily and ports if I go to something other than native VFP for my backend.

Part of the problem you have here is I'm extremely lazy. I like to sit and think a bit about my problem, so that things that behave the same way rely on a common class behavior. Remeber my bitch and moan about AccountMate not providing the source to their subclasses? I wanted to change a basic behavior of the control, so rather than cutting and pasting into a new class derived from the base class each time, I build a subclass that has the base behaviors that I want, and then start from there when I put things on screen. I don't have to code a grid and a column and adding a textbox each time. I drop my 'variable number of string data value thingy collector' class on my form, set a property with the name of the textbox subclass that describes the desired input line behavior, change the size or type of the single field I'm grabbing in the cursor, and it's done. And if I want to, I can put in an editbox, or a combobox, or anything else I want as the input control for the grid. It doesn't care. All it has to do is populate and validate its .Value which is passed back as a string.

As I usually say, YMMV.