Nadya,

Yes I do call it simple. You create two classes a textbox and a container. You write minimal code in the textbox class, probably no more than 10 or 12 lines. You add a couple of properties and a method to the container and you add a few lines of code to the container's Init to add in the textboxes and set their controlsource. When you have done this you have a relatively reusable class that can handle entry of multiple values for building an INLIST() argument.

With design, coding, testing, and debugging it shouldn't take any longer than a couple of hours. Once it is built and tested it can be used in a form in minutes. If one decides to add more time to the design and coding it could be made even more reusable and flexible and pay back would be even higher.

The day will come when the usewrs or client will require data validation in one of these situations and then you will be required to provide it. If the validation is causing you problems now, even though you are only doing it because you think it would be nice, there is a problem. We are only saying that the root of the problem is in the use of the editbox which is designed for freeform text being used to enter multiple formatted values (not freeform at all).

BTW, the argument against cursors can also be overcome fairly easily. Two approaches that will work.

1) make the form that collects the criteria use the default data session (and be modal which it probalby should be anyway), when called from a form with a private data session it will use the calling form's data session, so its cursor will outlive it and be available to the calling form as long as you don't close the cursor.

2) Use the same data session set up in #1 but create the cursor in the calling form's code before the call. Let the criteria form manipulate that cursor. When control is returned to the calling form the cursor will have the data put in it by the criteria form.