>>>>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.

I used this approach long before OOP, keypress or interactivechange was invented. That's why I wrote "the good old days". Today it's much easier, but you know how it is, as long as it works....!