Terry,

Hm, very strange. I haven't noticed this behaviour either.

I did some testing and found that assigning a value directly works:

Form.TextBox.Value=1.02043557              && displays 1.02043557
Form.TextBox.Value=102043557 / 100000000   && displays 1.02000000 (in my case)

It looks as VFP is ignoring the setting of inputmask when displaying calculated values.

Following is an extract of FoxHack about SET DECIMALS:

...When you perform a calculation involving decimal numbers, SET DECIMALS sort of determines the number of decimal places in the result. To be more specific, it determines the number of decimal places you'll see in the result, if the result has more places than the current setting...

Somehow this behaviour seems to be by design, though I think that VFP should respect the setting of inputmask.

The easiest way I found to fix this problem is to add a TextBox.value_assign method and add the following code:

*-- Method value_assign
LPARAMETERS vNewVal
IF VARTYPE(m.vNewVal) = "N"
	*-- force VFP to correctly display the number of decimals specified in the inputmask
	THIS.VALUE = m.vNewVal * 1.0000000000000000000
ELSE
	THIS.VALUE = m.vNewVal
ENDIF

>Having worked with VFP using high precision numbers, and not noticing this behavior, and wondering why:
>A form with a textbox. The format is "R" (read input mask) and the inputmask is 999.99999999.
>
>? outputs the expected value inside a transform
>TRANS( 102043557 / 100000000 ), returns 1.02043557
>
>But when assigning the texbox value:
>Form.TextBox.Value=102043557 / 100000000, the output is 1.02040000
>
>The set decimal is the default 2. When decimals is bumped, the resolution is as expected. Also odd is the fact that at decimal 2, the decimal is four in the TextBox. Can I get the accuracy through the format and inputmask properties, or do I need to bump up set decimals?
>Thanks