I believe tha manual is wrong describing the Currency data type. An Int64 can only guarantee a signed number of 14 integer digits + 4 decimals, instead of 15,4 as described in the manual (+/- 99,999,999,999,999.9999) because anything bigger than 922,337,203,685,477,5807 or less than -922,337,203,685,477,5808 will overflow, crash and burn 
(0x7FFFFFFFFFFFFFFF and 0x8000000000000000).
[quote=172681:@Dale Arends]Just for fun I tried them as integers, scaled as necessary. On Windows 7, Xojo 2015r1
dim Value1 as Double = 46.78
dim Value2 as Double = 1.509
dim Value3 as Currency = 46.78
dim Value4 as Currency = 1.509
Dim Value5 As UInt64 = 4678000000
Dim Value6 As UInt64 = 1509
dim Result1 as Double = Value1/Value2 ā = 31,00066
dim Result2 as Currency = Value3/Value4 ā = 31,1866
dim Result3 as UInt64 = Value5/Value6 ā = 3100066
Since Doubles and Integers are in agreement I can only assume that Currency is doing something wrong.[/quote]
I believe your Result2 is a wrong usage. You should not divide dollars by dollars. Makes no accounting sense. Value3 should be divided by another standard numeric type, such as double. When I divide currency by a double, I get 31.0007. Why the fourth decimal is rounded still remains a mystery, but the first three decimals are good.
One thing is for sure, Currency merits an overhaul if Xojo wants to enable its users to produce reliable accounting programs without resorting to workarounds. Otherwise a broken Currency should have no place in the language. And precisely, since the Int64/1000 workaround seems immune to current currency foes, it looks feasible to fix that issue without breaking everything.
dim Value1 as Double = 46.78
dim Value2 as Double = 1.509
dim Value3 as Currency = 46.78
dim Value4 as Currency = 1.509
Dim Value5 As UInt64 = 4678000000
Dim Value6 As UInt64 = 1509
dim Result1 as Double = Value1/Value2 ' = 31,00066
system.debuglog str(Result1)
dim Result2 as Currency = Value3/Value4 ' = 31,1866
system.debuglog str(Result2)
dim Result3 as UInt64 = Value5/Value6 ' = 3100066
system.debuglog str(Result3)
dim Result4 as Currency = Value3/Value2 ' = 31,0007
system.debuglog str(Result4)
dim Value1 as Double = 46.78
dim Value2 as Double = 1.509
dim Result4 as Currency = Value3/Value2 ' = 31,0007
system.debuglog str(Result4)
Think itās best to keep the doubles and convert to currency just for presentation on screen or reports.
Um, no. Used to work. Now it doesnāt. Bug. Period.
Currency needs love urgently.
+1000
FB 21197, created back in 2012
I just made a new case for the math error above.
It works right in Real Studio, but fails in Xojo.
case 41711
I am fortunate enough. The extent of my accounting software so far is an electronic checkbook. So it deals only with cents, additions and subtractions. I went Int64 to calculate everything in cents and simply format the result.
I still think it is pretty preposterous that currency, which is a very critical type, be in such a state of abandonment.
This is the kind of detail that can not only be a show stopper for certain developments, but also give a bad reputation to Xojo as a toyish tool.
And now Christian has even found a regression !
Maybe we should all write a letter to Santa and light a candle at the altar of Saint Isidore Of Seville. If I knew of a Bodhisatva for programmers, I would also recite his mantra. At this point, only a higher power can have mercy on us it seemsā¦
That is really the case. I voted Xojo as something like a toyish tool in a product review, because the company sees no reason to resolve such unnecessary bugs in years of knowledge about them.
From my point of view bugs in data type behaviour and standard controls are not acceptable and should be fixed immediately.
I like Xojo an use it for my own hobby to develop software, but I have problems to suggest Xojo as a tool for professional software development in a corporate environment.
I donāt agree Torben.
With Xojo you can develop high-tech x-plat software in just a short period of time, you must be prepared to create workarounds where you did not expect to spend time, true. Once you get experienced and have a code library and a bunch of custom controls on your shelf, you can kick off with projects very fast and flexible. And next, where will you find a community so direct and willing to help and share solutions for typical problems you faceā¦ ? Together with the Xojo Inc. team impressive things are made with Xojo. I do agree with those who want just a period and a few release for just bug fixing and stabilizing rather than adding new things, especially for fixing issues this thread was about.
I am a die hard fan of Xojo. But if I were to advise development of an accounting program supporting the new tax schemes and VAT, I would probably be quite embarrassed. I frankly do not see myself telling someone Xojo supports currency.
Sure, there are workarounds. But it is a pity that a fundamental building block of a language such as a data type be so flawed.
The question of the currency type issue has been discussed here many times, but it seems to fall on deaf ears. Pity again.
As for stopping new developments to fix old bugs, it does not seem realistic. The software market is a moving target. Windows was 90% of the market for 25 years or so, until came iOS and Android. Now they would be lucky if they get 19%. Unlike developers seated on a niche market, for instance corporate clients in a long term relationship, Xojo cannot survive catering only to the good old platforms. By essence, they have to be where new developers are. Where most old clients as well, if they want to survive in a changing landscape. Maybe not those stuck in the RB era and the never ending beaching, but, rather, those who actually pay Xojo engineers with renewals and new licenses.
I have a been a very vocal proponent of iOS and remain so, even if for the moment I did not crack the secret to a killer iOS app. I do not quite see what I could do with a Raspberry Pi as I misplaced my soldering iron quite a while ago, but I do see how this can be a tremendous advantage in the Internet Of Things market. Life must go on.
A clear message !!!
Having built accounting apps I wouldnāt use currency anyway - personally a BCD type or use Bob Delaneys infinite precision plugin
The accountants I worked for liked precision beyond 4 decimal places esp for intermediate calculations
They often expressed rates for sales and a thousandth of a cent conversion on a few hundred million $ makes a big difference (esp if it involves calculating someones commission) They were always oddly based like ā1/1000 of the current price of aluminum on the Chicago mercantile as of some dateā or even worse where it was a fractional amount based on the the rate between two commodities. But it was always a dollar amount with lots of decimals - not a percentage
When I did this we used a language reminiscent of Cobol and all ācurrencyā values were decimal(15,6) - 15 digits preceding the decimal 6 following
Fact is that currency is there and so:
is true.
I know BCD would be way better. But IMHO the big issue is that Currency should behave as described, and simply perform as advertised.
BTW : apparently no feature request for BCD.
currency should be treated as 2 int64, one for the integer part, and one for the cents
you need exact results, the .0000000001 are not allowed in financials programs.
should not be difficult to arrange some class to deal with that in a transparent manner ? 
edit: one int64 for the integer part and one int smaller (16 bits should be enought) for the cents