>>>>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.
>
>Thank you. I am glad it makes sense to you, as I was thinking that maybe this approach was only valid in dBase for Windows. And I thought that in VFP I should change it. I am glad I asked a stupid question before rewriting the entire code <g>.

Today I would use Keypress or Interactivechange. I used this approach long before OOP was implemented in VFP.

BTW, "there are no stupid questions, only stupid answers".