|Date:||Sat, 7 Apr 2018 13:48:57 +0100
|From:||Michael Kennedy <Info@KennedySoftware.ie>
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,
- 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!
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
> Collectibles and Memorabilia
> Vintage Lego Sets and Parts
> - and Paradox support, too
> "Michael Kennedy" wrote in message
> 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
>> 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
>>> Collectibles and Memorabilia
>>> Vintage Lego Sets and Parts
>>> - and Paradox support, too