>Jim,
>>
>>First, you can set the Format of your editbox to 9 and the Maxlength to 5 and use the same code I sent you.
>
> I read Help about Format function and haven't seen 9 as one of possible formats. I'll try anyway. But it seems to me, that editboxes don't recognize format settings. I tried ! without any effect, I tried A, and I tried combination of them with no result. Can not imagine, why?
>
>
>If you would look you would see that.
>>
>>Secondly, why an editbox for a 5 character value?
>
> Jim, I feel obligative to explain again my intentions here, even if I did it several times in other threads. I want to use editbox (and I designed class btcc_edit, based on it) to allow our users specify multiple choices in most convenient way. Right now I'm using this class for zipcodes and zip sections, but, of course, I can use it for any criterion, like owners (right now I use btcc_text for this - so only one choice), etc. The users may type:
>12345 (Enter)
>24567 (Enter)
>01235
>etc. and I reconstruct my criterion as INLIST(zipcode,'12345,24567,01235').

Then you're constructing it wrong - INLIST() with this list would have to appear as:

INLIST(ZipCode,"12345","24567","01235")

This is easier to do from an array or cursor where each 5 character string is discrete; to do this with a string, you'd have to parse the string and STUFF() delimiters to make it work right.

Think about this - Ken Weber, Edward Pickman, Erik Moore, Jim Booth and I all agree that there's a problem with this approach. Is it possible that we might have some idea about this? I'll admit that I have clients that pay me not to design their UIs, but I do deal with lists of Postal Codes all the time - I do shipping and logistics stuff. The others don't have end-users threatening to shoot them when the first cut of a form is delivered.

To be honest, your btcc class should not care what control produced the list - if it really has to be an editbox, then there's a coupling problem that should be untangled - anything that can produce a character string with the list of values should work in place of an editbox. In fact, you want to store and save the string, or at least at one point indicated that you did. I'd defer to Jim on this - he's very good at explaining the concept of abstracting an interface and tight vs loose coupling - he's done some outstanding sessions at DevCons and the like in the past.

>I expect, that our users would not type a lot of them, no more than 5-6.
>So, in editbox valid method I analyze each line, that they type.

What's the difference, aside from having to write code to do this, with using a textbox for input, which has an InputMask property that can help you restrict the character set? You're working much too hard on this control, and it's not going to be generally useful or reusable. You're doing this much work to make this one case work. The time you're spending to do this now doesn't pay off if you need a list of 4 character long IATA (airport) codes, or 6 character long Canadian postal codes, or 10 digit Social Security IDs, or any of a number of other "input a list of things that are alike on the basis the following template", so you need a list thing (maybe a listbox or grid?) to hold the currently accepted values, a textbox perhaps to edit or add the current member the currently-selected member. And something that takes the list and formats it as if you'd put it in correctly into the value of an EditBox.

At some point, it'll sink in that "If it started out as if it were really simple, but now looks really hard to do, maybe it's the wrong way to do it."