Ed,

>>>>ekp is just a variable to check the number of keystrokes. When it reaches 5 an enter key is automaticaly pressed and the variable ekp is set back to 0.
>>>
>>>Do backspaces count as keystrokes?
>>
>>Yes, they count and they should not. They should also be only digits, not characters. I think, it's necessary additional check here. And I also don't like an idea of public variables. I'd better make this variable to be a class property.
>
>I don't think you understood the question - it's not an issue of whether the KeyPress event should respond to a backspace (it should IMO), it's a flaw in the methodology to maintain the data in the control.
>
>You're trying to do this in the most difficult way I can imagine to approach the problem of fitting the input to the class interface. You have a UI requirement that states that if a value exists, it must consist of 5 valid characters that can be validated against a master list of zip codes (there's no pure numerical method to filter out legally constructed but unassigned zip codes AFAIK) in the case of a US Postal code, a 5 character string consisting only of the digits 0-9 (you're going to really, really dislike Canadian Postal codes, which are 6 characters in length, and alternating character positions are all digits or all uppercase letters. And then we get into the Zip+4 system that's been in play now for several years...)

I think you're jumping to conclusion without understanding this particular problem itself.
Ok, let me explain my choice, BR, etc. As I wrote several times, I was working on the project, which allows our users make their selection criteria.
That is that it should do. This application doesn't involve any 'master' tables, only lookups tables for populating btcc_multilists. I placed lots of criteria on the form, and designed several classes like btcc_text, btcc_check, btcc_options. When I almost finished my form design, my manager came and told me, that it would be nice to have an editbox for zipcodes and zip sections. So, it even was not my idea to implement edit box from the beginning. Ok, I designed this class, found few problems during development (state-restoration problem), resolved them with some help from UT. At this point Ed Pikman advised me to change into grid instead of editbox, and you were the person, who applaud this idea. I considered it too, but then I started to think about all hassles, that would require by this approach and finally decided, that editbox is simpler and better. I want to remind you also, that nobody asked me about such validation here, it was my personal idea from the beginning to do this check.

Anyway, I hope after explaining you these details you would not insist to switch into another control anymore. I can totally forget about the 'checking idea', or I can do it the way I was thinking at the start point - e.g. check in the valid method. I still don't think, that it's a hard task - just few lines of code. I assume, that our users would not type more than 5-6 codes, so if a typo occurs, they can easily find it.

Meanwhile, I came up to idea, that it would be great if a standard editbox have few new features, like maxnumber of strings or input mask for line. I put it into VFP7.0 wish list. I also think, that in the standard PageFrame we should have page.visible property (see Mike's Helland class for this). I also put it into VFP7.0 wish list.


>I'd do what I could to create a control that only allowed one item at a time to be edited with fixed formatting and verification, and then convert the input to the format needed by the btcc class. Without having seen the semi-mystical btcc class, I'd guess it would be easier to collect the data and ease the data entry task, and then convert it to the format the btcc class required. The btcc class shouldn't give a damn what type of control was used to input the data (or even that it came from a control and not some other data source) as long as the value passed in to it was in the expected form.
>
>At some point, it'll be easier for you to abstract the interface between the editbox and the btcc class than to try to make the wrong control act the way you'd like it to behave.


As I said, it's not critical to behave this way. At least nobody but me expects this behavior.

Anyway, thanks for your help, I really appreciate it. Next time when I'd design something I'd consider all possibilities first. But right now I don't want to mess working fine application.