There are really no settings you can change. You would have to use a TWS API Version of at least "163" for any of the fractional size rules to work. rossh_yh mentioned that "163" is available in TWS API V10.10 and later. And it sounds like IBKR now requires fractional size support for AUD.USD real-time data.

• for C++ in "CppClient/client/EDecoder.h"
• for C# in "CSharpClient/client/MinServerVer.cs"
• for Java in "JavaClient/com/ib/client/EClient.java"
• for Python in "pythonclient/ibapi/server_versions.py"

Your client can also be aware of the maximum API version it understands and, after connection with TWS/IBGW, the highest common version. This is somewhat language dependent again, but in python, for example, these two lines below should be able to print the API version for you and it should print a number of 163 or higher for fractional siye support.

from ibapi.server_versions import *
print( MAX_CLIENT_VER )

闯ü谤驳别苍

PS. Excuse my PSL level python skills (Python-as-a-Second-Languge) but we speak Java at home

I guess it's because you use 000, which if I remember well require that you call by reference.
Try 100

I use
Look at the readme and bid_conf.h
Makefile does generate a bunch of variety of lib to deal with various implementation and calling convention.

Things like
First digit require that you do use calling by reference. 100 is by value etc ...
Second digit is rounding options.
Third is about a global config for some implementation definition of exception.

I think I use 100blibbid
I use "by value" because the hidden type is 64 bits, which is same size as a ptr (64 bit cpu), it help (marginally) compilers to optimize procedure.

so either you learn the naming convention of the lib(s) you need,
or workaround you directly put the source file of the "Decimal" lib in your IBKR lib project compile and debug to see if it fits your calling convention.
There are only a dozen .c files needed. Not pretty but allow easier debug of it.

开云体育

Atop excellent answer from 闯ü谤驳别苍
I may mention some caveats of Decimal from C/C++ perspectives (that may be source of inspiration for other language)

- On 64 bits machine (and I suspect regardless of the OS) the Decimal is hidden under a "long long" (it maybe language dependent although)
Default use can be seen signed as a __int64 for linking.
Warning, this allow some compilers to cast to/from double without any warning!! (can happen too with cast to/from __int64 or uint64_t)

Otherwise said it use 8 Bytes/ number (The official standard allow 32 bits as well as 128 bits encoding aside of 64 bits, I saw IB using it in 64 bits which is default and good enough)
"Decimal" should NOT be caste directly to a simple type as it use a very specific bits organization. (so different from a double or __int64 that it create huge errors that you will not missed on first run).
If you need type conversion, simplest way is go trough Decimal to String then String to double or int or whatever using regular ASCII to float/etc ...) generally fast enough if done only once.

- FYI: Decimal is not an invention from IB, it is standardized and there are various open source lib, like from Intel or IBM to help supporting it. (And IB does supply a Decimal lib with it's example)

- Once in "Decimal" you should stay in Decimal and use Decimal operators.

There have been many changes between TWS API V9 and V10, but the one with the most impact is the transition of most "size" fields in classes and method signatures from "int/long" or "double" types to a "Decimal" data type. You need to look at the TWS API source code for the language you are using so see what that means exactly for you, since their approach was a little different for each language. Take a look, for example, at the totalQuantity or filledQuantity fields of the Order class in one of the more recent V10 versions.

"Decimal" math assures stability to the right of the decimal point/comma well beyond what floating point math can achieve. That became important with the introduction of fractional shares and crypto trading. You don't want to lose a small fortune just because trade quantities accumulate impressions every time you do a simple math operation.

• You would get 2.5789999961853027 in standard "four byte float" math
• You would get 2.5789999999999997 in standard "eight byte double" math.
• While you get the expected 2.579 with a "Decimal" data type

"Decimal" types are generally more cumbersome to work with, though, since have to call methods even for simple arithmetic functions such as a.plus( b ).multiplyBy( c ). But details, as I said, are language specific.

闯ü谤驳别苍

We had topic No historical market data for AAL/STK@VALUE Last 1d in august with a similar issue. At the end this is probably a question for IBKR, though.

闯ü谤驳别苍

Strange, I have the same problem but when I use AMEX as the exchange it works...