>>Hello.
>>
>>A difference in the way VFP 5.0a textbox controls and VFP 3.0 textbox controls behave has been noticed here.
>>
>>Here is an outline of an example:
>>
>>All properties set to default except
>>ControlSource = SomeTable.SomeField && SomeField is N(9,2)
>>Format = 999999.99
>>
>>You tab to the field and enter
>>
>>234.66
>>
>>You are now at the next control with 234.66 in the textbox. Then you
>>
>>>5.25
>>
>>In VFP 3.0, you would have 5.25 in the textbox. In VFP 5.0a, you would have 523.25. I think we can agree that the value in the textbox should be 5.25.
>>The problem occurs when you hit the decimal: In VFP 3.0, everything to the right of the decimal (but before the 'old' decimal) is wiped-out; in VFP 5.0a, nothing is wiped-out when you hit the decimal, so you retain some of the data that you probably wanted to lose.
>>
>>Along the same lines, if you change the SelectOnEntry property to .T., some of the behaviour is avoided. But if you have an input mask of 999,999.99 (or anything with commas) you run into problems. If you have this field and go to it when the initial value is zero and you type 3, the zero stays in the field to give an resulting value of thirty. This only happens the first time you enter the field.
>>
>>I am wondering if an InputMask of 999,999.99 (ie. commas with 9's) should not be used. Or is this a bug? Or is it something else...
>>
>>Thanks for any information.
>>
>>Joe
>
>If you put K in the format property, this will wipe the whole thing out as soon as you press a key. This, I believe, is the same as you say VFP3 works.

It isn't the same, but it is acceptable behaviour.

Actually, do you know the difference between a Format of K and a SelectOnEntry of .T.?

Thanks,
Joe

Joseph C. Kempel
Systems Analyst/Programmer
JNC