>>>>My *guess* is so that the characters actually entered by the user can be idntified. Spaces entered and the like.
>>>>
>>>
>>>I kind of sort of see what you are saying but not quite. That is, on the surface of it, the KEYPRESS method can "get" the value entered in the textbox (space of otherwise) and Seek on it.
>>>
>>>>Does it strip out the 255s before it SEEKs?
>>>>
>>>
>>>The Chr(255) is "stripped out" by VFP itself. That is, when the stuffed Chr(255) fires KEYPRESS method, the KEYPRESS method processes the value in the text box (seeking on it) and it gets rid of the Chr(255).
>>>
>>>Thank you.
>>
>>Even though you can "get" the value entered, it's much easier to replace the starting chr(255)'s with the value. I know, because I used a similar solution myself in "The good old days". Especially backspace gave problems with the seemingly easy problem. Also the CHR(255) solution made it much easier to see any trailing spaces entered by the user.
>
>Imho, using InteractiveChange event instead of KeyPress would eliminate all issues.
This is interesting. I will see if I can rewrite my routine (as a test) using InteractiveChange method instead. Thank you very much.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham
