> If the calc is "internal", and not associated with the displayed value,

thing is, I assumed it was "internal", as you phrased it, but it's not.. 
consistent with all previous logic, the format control is on the 
"appearance" tab, not the "properties" tab.. and the object on the form is 
the actual field

as a programmer, there are ways to overcome this, of course, but this is 
default behavior that a noob would never notice.. hell, it took me a long 
time to notice.. and a really really really tiny value that didn't match

in this particular instance, []= .0025, not .003, so unless somebody jumps 
in and points us to a changeable property that can control this, this is 
technically a fatal flaw in PdoxWIN

I'm gonna go dig thru Bertil's buglist now..


--

Steven Green
Myrtle Beach, South Carolina, USA

http://www.OasisTradingPost.com

Collectibles and Memorabilia
Vintage Lego Sets and Parts
- and Paradox support, too
"Michael Kennedy"  wrote in message 
news:5ac8be38$1@pnews.thedbcommunity.com...

I understand, Steve,  but..... just to re-phrase...

Type 0.0025, and that goes into the table. Irrespective of Format(),
W.NN, etc... (And I assume this applies to both "$" and "N" fields).

If the displayed value is 2-decimals, with Format(), or W.NN, then 0.00
should appear. 3-decimals (rounded) should show 0.003 for "N" fields,
but still probably just 0.00 for "$" fields.

If the calc is "internal", and not associated with the displayed value,
then:
   - If the field is type-N, the calc should use 0.0025.
   - If the field is type-$, I think it still uses 0.0025, but I'd need
to check this - it might use a 2-dec rounded value?

If the calc is using the displayed value, (eg, a TotalValue = Qty *
Price on a form), then it probably should use the displayed value - for
consistency? Irrespective of the $/N field-type?

So, maybe the usage you're seeing is OK?

Also, in case you're digging deeper into this strange calc stuff in the
app, watch out also for NEGATIVE values!

Mike


On 06/04/2018 22:11, Steven Green wrote:
> Mark.. no, useage.value is the same as the current format.. wow
>
> Mike.. yes, in PdoxDOS, any math based on [useage] would of course be 
> based on the actual field contents, regardless of the display format, 
> unless you specifically format it or round it.. in PdoxWIN, I had assumed 
> the same behavior, in the same context, all these years.. but I didn't use 
> "format" like this guy did, in the form I'm working on, to squeeze a 
> gazillion things on screen.. I would not have anticipated these results, 
> because I would never round a number field that way, in a data entry 
> process
>
> it lets the user type in any number of decimal places, rounds to the 
> "format" level for any action you take, but sticks what you typed into the 
> field
>
> type in .0025
>
> with "w.3" display, any code uses .003 as the field value, then puts .0025 
> into the field
> with "w.2" display, any code uses .00 as the field value, then puts .0025 
> into the field
>
> if you type into a raw table, and not a form, you're just typing in .0025 
> but there's no code attached, of course.. any queries or scans, after the 
> fact, will use the real field values
>
> geez, this is stupid !!
>
> -- 
>
> Steven Green
> Myrtle Beach, South Carolina, USA
>
> http://www.OasisTradingPost.com
>
> Collectibles and Memorabilia
> Vintage Lego Sets and Parts
> - and Paradox support, too
> "Michael Kennedy"  wrote in message 
> news:5ac7c63e$1@pnews.thedbcommunity.com...
>
> On 06/04/2018 19:19, Steven Green wrote:
>> Mark, I'll try what you said.. Mike, yes, making the display "w.4" solves 
>> it
>>
>> problem is, that's supposed to be "display" formatting, not "field" 
>> formatting.. never noticed this before.. something like this has HUGE 
>> implications, in theory
>
> If the calc is associated with the displayed value (W.2, W.4, ...), then
> it might make sense?
>
>    - Mike
>
>
>
>> That sounds vaguely familiar.....  could actually be useful if it you
>> knew about it and it was consistent.
>> Have you tried the difference of:
>>   usaage * tc.unitcost
>> vs
>>   usaage.value * tc.unitcost
>> ?
>> -- 
>> Mark B
>>
>>
>> On 4/6/2018 11:13 AM, Steven Green wrote:
>>> I have a field called Useage.. no formatting or rules on the actual 
>>> field, just a raw Number field that often has up to 4 decimal places
>>>
>>> on a form, I display it "w.2", but I can click on the field and see the 
>>> actual value, if it's .025 or anything like that.. so far, normal 
>>> behavior that I expected
>>>
>>> but when I use that field in a calc, it's using the formatted version of 
>>> the field, not the real field.. in the example above, it showed me .03 
>>> on the form, of course.. I clicked on it and saw .025.. it did the 
>>> resultant math with .03.. but I look at the table afterwards, it's .025
>>>
>>> useage * tc.unitcost
>>>
>>> in my example, tc.unitcost is 182.. times .025 is 4.55, times .03 is 
>>> 5.46.. it's displaying 5.46
>>>
>>>
>>> ??!?@@$??
>>>
>>>
>>> -- 
>>>
>>> Steven Green
>>> Myrtle Beach, South Carolina, USA
>>>
>>> http://www.OasisTradingPost.com
>>>
>>> Collectibles and Memorabilia
>>> Vintage Lego Sets and Parts
>>> - and Paradox support, too
>>
>