order.totalQuantity = stringToDecimal( ¡®100¡¯ );as in, pass the quantity as a string that gets converted using the ¡®stringToDecimal()¡¯ function
.totalQuantity is a "Decimal" type, see many other threads on the subject of Decimal.
I am not sure there is really a bug in the sense of what you describe. Nothing surprising in what you report.
You Cannot do thing like totalQuantity=20.0,? as Decimal doesn't have a default implicit caster for double type. (that I know)
The simplest way to make a Decimal is to go from a string, as you did it, the conversion time is absolutely marginal (microsecond range)
You need to enter the 'Decimal? world' then stay using Decimal.
What is very dangerous is the unsafe and non-warned (compiler) capacity to assign a double to a Decimal (as Decimal use an underlying type unsigned long long) ,
without understanding that the Decimal will wrongfully be overwritten at bytes level by the bytes of the double (assuming you use 64 bit implemented Decimal which is the default with IB example.)
This create "crazy" Decimal that have nothing relevant as value, even close, to value of the double. This is as unsound as doing __int64 v = 1234;??? double d = *((double*)&v);
This might very well explain some strange behavior of an order rejection.
Way to diagnose and comfort yourself is to convert back "totalQuantity"? using decimalToString(...) then from string using atoi() and check that it match your request.
BTW there is no safe conversion from double to Decimal (even if it is safe from Int to Decimal) and double is not a safe type to encode fractional values, hence the switch of IB to use of Decimal to safely support fractional quantities.
