"Money" type decimal entry in X

Simple question #3
I know the “money” data type has gone away in PanoramaX. No biggie. The only convenient feature of it was the ability to enter your numbers without the decimal point and have it assume the last two digits were after the decimal point.

I saw in a reply to a question on the forums a year ago that this had not been added at that point (July 2016).

Is there any chance it’s been added in the past year, or is there any plan to add in the future? It’s not a huge deal. I can learn to type decimal points again, but it was helpful.


Peter F

If it were to be reintroduced, it would be great if the money data type was also stored as an integer or fixed point as it would reduce the incidences of FP rounding errors, which are strange for a money data type.

Setting a field to Number (Float) with an output pattern of #.## should give you the result you’re looking for. You may want to make the output pattern #,.## in order to include the comma in thousands.

This won’t solve the rounding error problem. If you have 20 records, each containing a calculated (say by adding sales tax) amount of $10.245, each will appear in the data sheet as $10.24 and if you add them manually you will get $204.80. If, however, Panorama adds the field, the displayed total will be $204.90 because the 20 extra $0.005 values will be included. The easiest way to avoid this discrepancy is to use the round( function to calculate each value. Then the displayed value will equal the stored value.

Interestingly, the round( function will convert each stored value of $10.245 to $10.25 and the total becomes $205.00.

Yes round( works. A bit frustrating having to use it all the time in order to make 100.000001% sure the money calculations are correct!

“Money”, as a data type, (in most countries) comprises two components (Dollars and Cents) glommed together and both of which are integers

I don’t think this suggestion addresses the question of data entry. I would find it VERY helpful, if I could enter money amounts without needing to put in the decimal point. Is it possible??

Yes. If you had a form with a text editor object for a floating point number, where the user is typing in the amount, you could add a formula that is triggered when editing is finished that divides the entry by 100, but only if the value has been changed.

if info("modified")=A

To elaborate on Tom’s suggestion, you could add the code to field’s code property which would simply check to see if there is already a decimal point in the entered value and then convert it if none was found.


You could also use this if the target field was text by altering the code:

if «»[-3;1]≠"."

Once set up this will work the same whether in a form or directly in the datasheet.

Playing around, I’ve found a way to at least approximate the look of the missing “Money” data type. The main complaint from its lack is that using floating point, instead of integer, math induces rounding hassles. First, instead of storing money as separate ($, €, etc.) plus decimal cents, store the full value in cents. Panorama’s 64 bit integers provides a range of ± 90 Quadrillion to the nearest cent, which should be vast enough any stable currency, albeit not for worst case hyperinflated ones. You’d have to carefully keep straight the implied units of your numbers, potentially integer dollars, integer cents, or floating point dollars & cents to avoid 100x conversion errors, a doable task I leave to you. You’d also have to watch the rules for combining numeric types (Panorama Help > Numbers) if you want to keep your results as integers and avoid rounding.

The real problem then becomes we humans would want to see “integer” cents displayed with a decimal point before the last two digits. Panorama’s output patterns don’t precisely allow such. An Output Pattern of #.## would display a floating point dollar plus cents like 1.23, but same pattern would display the integer cents as 123.00. But Panorama X offers additional Numeric Pattern options, specifically those for Multiple Component Numbers. The Help Wizard offers Pattern “###-##-####” as an example for use with social security numbers. Other characters can be displayed as text at specific positions within floating point or integer numbers." Alas, the “.” character (Unicode 002E), aka “period,” aka “decimal point” is privileged within the Numeric Patterns and can’t be used that way.

However, Panorama X now supports Unicode and its vast array of characters offers options that look like a “decimal point”, but aren’t, and can be used just like the “-” characters in the social security code pattern. The best alternative in many fonts seems to be “․” (Unicode 2024), “One Dot Leader.” It looks identical to my eye in both appearance and spacing within the Formula Wizard to a “decimal point.” Giving integer 123 cents an Output Pattern of #․## displays that integer as 1․23, when I use Character viewer to search for 2024 then enter it there instead of a decimal point. So far so good! But if I change the integer to 1234 and use that Output Pattern it still displays 1․23, not the desired 12․34. Not so good. Changing the Output Pattern to ##․## displays 1234 as 12․34, but displays 123 as 01․23. You have to add enough leading “#” characters to your pattern to allow for the possible length of your integer and you have to put up with leading zeros for shorter integers. If you want to display commas every three digits you can provide them, but may have to put up with leading commas if your integers vary enough. I don’t see how to avoid the leading extras showing in the data sheet. But if your integer cents are to be displayed via the pattern( function, as on a TDO or some other formulaic output, you can build a variable reflecting that integer’s length [eg. ?(length(integer)<4, "#․##",rep("#",length(integer)-2)+"․##")] to use for the functions pattern and avoid the leading extras.

In principle the above method could also be used to mimic other “fixed point” data points while allowing for integer rather than floating point math. For non-US systems that use different separators for decimal numbers you’d need to find a Unicode look alike for your comma, etc. Such are probably available although may not be available in all fonts. Whether the hassles involved herein are a good trade for the rounding hassles involved with using floating point math for money values I leave up to you.

I suspect the inelegant data sheet display issues could be resolved by Jim adding additional characters to the Numeric Function toolkit, versions of “#” and “,” that would only display in Multiple Component Numbers when there were sufficient digits available. I also suspect Jim would prioritize that addition to the bottom of his very long list.

You could easily set up a different response to a numeric entry by varying the termination key. For instance, terminating a value with the ENTRY key could automatically add “.00” to the end of your entry and terminating with a TAB or RETURN could treat the last two digits as cents. The info(“keycode”) function will tell you which key you used.

The downside is that this approach requires greater intellectual rigour than most of us are accustomed to.