Thanks, that might solve the issues.

I guess if I sell through TWS I will get QTY = 0 position update, if I buy I get the QTY!=0 position update, which solves the problem to understand if the order is Buy or Sell which is missing in orderStatus/execDetails callbacks.?

Thanks

When placing an order through the API I frequently get a callback within 70 ms or less showing IB has received the order.? I have identified a set of circumstances where IB will repeatedly delay about 1,100 ms before even acknowledging they have the order.? Sending the order out for execution happens soon after their acknowledgment of receipt.? This excessive delay has nothing to do with network communication delays (I'm 12.5 ms from their server on 1 Gbps fiber with AT&T).? I'm placing US stock orders and using the SMART router with default settings.? The sweep-to-fill order type is obviously designed to get faster execution by targeting lit liquidity.? But if IB won't even confirm they have the order I'm not sure this will help.? Can anyone comment on their experiences with the sweep-to-fill order type as opposed to a regular Limit order?? Is anyone willing to share their research on the circumstances that cause IB to hold an order for 1,100 ms before confirming they have received it?? This is not random but I'm not yet wiling to describe how to reproduce this issue because it requires an explanation of market conditions that relate to a particular trading strategy.

Hi All,

I've recently (maybe last two weeks) been getting this message on some of my charts.? They won't load.? This happens immediately after the daily re-boot.

Sometimes I can just hit refresh, but that rarely works.

I change the instrument to another and then back, that works sometimes.

Eventually (?hours later) it seems to clear up.

Is anyone else experiencing this?

TWS 981

Thanks, as always, and be well,
Lou Dudka

I guess the confusion may come from the fact that immediately sends you a snapshot of all current positions followed by a call of AND, as Steve described, continues to send you position updates for those and any future positions until you call .or your client exits.

It basically makes your client know exactly what TWS shows in the position window. That includes positions that recently were closed (e.g. have a quantity of 0) as long as TWS still shows them.

闯ü谤驳别苍

I only call reqPositions once after the TWS connection is made and the Positions callback function executes after every change of position.
-st

Thanks 闯ü谤驳别苍 for taking my attention to MasterClient ID.

Actually I have realized that I have overlooked the documentation which states MasterClient ID is unset initially in TWS. I was using client Id 0 and was assuming it is the masterclient but not set in TWS. After setting Master Client ID () I do receive execDetails call backs for the sell executions for the orders which is directly placed from TWS GUI. I need to figure out the order action(Buy/Sell) in the application somehow but main issue was solved which was due to unset MasterClientID.?

Thanks Edward for confirming my idea to have a GUI for my application. Monitoring signals, portfolio and P&L on text files/db tables/excel files tiring after all but developing a GUI also needs some effort. I will see how it goes.

Thanks Steve for reminding positions call back. Let me ask, can I leave it open/subscribed and get position updates always? or should I periodically request reqPositions to get updates in timely manner ?
Actually I wonder if I start application and execute reqPositions and get all the position updates as long as the application runs or until I send cancelPositions? I'm a bit confused in documentation which says positionEnd will be triggered automatically. Is it only for the first request which means I need to request reqPositions twice ?

Many thanks for your replies.?

Steve and Edward have pointed you in the right direction already. The only thing I'd like to add is that you can control how much information (if any) your client application receives about orders placed in TWS or by other client applications.

If you have not done so, take a look at the concepts of "client 0" and the "master client" in the section of the API Reference Guide. And since 0 is a legitimate value for the "Master Client ID" you can configure TWS/IBGW such that your client with an ID of 0 is both, a "client 0" and a "master client".

闯ü谤驳别苍

On Tue, Sep 20, 2022 at 11:32 AM, Edward wrote:

开云体育

I’m familiar with this situation. BTW - working with other brokers we face the same problem - sending order from their GUI cannot be tracked in your application as you cannot bind it to your algorithm. The only way we deal with it - never send an order from their GUI. For the purpose of such situations we use our own GUI that send such order. Then you can trace it. This is not a perfect solution as sometimes (rarely but still) the broker can decide to close your position.

One way I deal with this scenario is using the call back function.? It will return 0 shares after you close the position in TWS.
-Steve

Hi all,

I have a question for a case which I need to handle. During my tests I have experienced the following

a. API application generates a signal to buy and place the order, I keep the inventory of orders(id, action, qty etc) and portfolio(stockId, bought, sold etc)
b. TWS transmits the order and order is executed, orderStatus, execDetails, commissionReport callbacks are called
c. API application waits for a sell signal to be generated
d. At some point I decide to sell stock manually and I close the position on TWS manually.

TWS shows the stock as sold afterwards but in this case, I see that
1. I receive orderStatus callbacks - but the returned orderId is not the ones that I keep so I cannot relate the orderStatus with the existing portfolio of stocks.
2. I receive NO execDetails for this manual order.
3. I receive commissionReport, but again no way to relate it with a stock in my portfolio of API application.?
4. API application generates the sell signal because it does not aware that stocks gone, and make a Short Sell unintentionally

What would be the way to handle manual sells from TWS while the API application is running ??

Thanks in advance.?

On Tue, Sep 20, 2022 at 12:46 PM, thepeete wrote:

I obviously tried using the stock library provided with the API (IBJts.10.18/IBJts/source/cppclient/client/lib/libbid.a), but this is what happens:

You're saying you can't build the sample either? You should be able to IMHO. I tend to agree with 闯ü谤驳别苍 on this one... if they ship the library, use it.

As far as if your tick info is correct... IDK what instrument you're playing with but it's probably easy enough to look at some data spit out by software build against the old API and compare that to the new stuff for piece of mind.

The latest TWS API 10.18.02 ships with a makefile for C++ on Linux that contains rules for static and shared library client client compilations and uses the libraries supplied by IBKR. It also contains various command line definitions for g++ you should model your build environment around:

samples/Cpp/TestCppClient/Makefile.linux

I don't get copied on IBKR Engineering internals, but I guess the Decimal type for instrument sizes was introduced for crypto support. Standard floating point math cannot even calculate 1.123 + 1.456 correctly as 2.579 so you might be off by a small fortune when trading crypto instruments using floating point math of any size.

Decimal data types provide fixed point math where these calculations do get exact results. IBKR has defined math contexts that support correct fixed point calculations of up to 16 digits to the right of the decimal separator (dot or comma depending on where you live).

闯ü谤驳别苍

I'm using Arch Linux, which as far as I know doesn't have a package for libintelrdfpmath.

I obviously tried using the stock library provided with the API (IBJts.10.18/IBJts/source/cppclient/client/lib/libbid.a), but this is what happens:

g++ -shared? obj/Debug/ContractCondition.o obj/Debug/DefaultEWrapper.o obj/Debug/EClient.o obj/Debug/EClientSocket.o obj/Debug/EDecoder.o obj/Debug/EMessage.o obj/Debug/EMutex.o obj/Debug/EOrderDecoder.o obj/Debug/EReader.o obj/Debug/EReaderOSSignal.o obj/Debug/ESocket.o obj/Debug/executioncondition.o libbid.a obj/Debug/MarginCondition.o obj/Debug/OperatorCondition.o obj/Debug/OrderCondition.o obj/Debug/PercentChangeCondition.o obj/Debug/PriceCondition.o obj/Debug/SoftDollarTier.o obj/Debug/StdAfx.o obj/Debug/TimeCondition.o obj/Debug/VolumeCondition.o? -o bin/Debug/libtws_api.so ?
/usr/bin/ld: warning: bid_decimal_data.o: missing .note.GNU-stack section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
/usr/bin/ld: BFD (GNU Binutils) 2.39 assertion fail /usr/src/debug/binutils-gdb/bfd/reloc.c:8549
libbid.a(bid64_string.o):bid64_string.c:(.pdata+0x0): dangerous relocation:
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
compilation terminated.
Process terminated with status 1 (0 minute(s), 10 second(s))
1 error(s), 17 warning(s) (0 minute(s), 10 second(s))

This however compiles just fine with the libintelrdfpmath I built myself, but then, the values are wrong...? or are they?? I just used the decimalToString function provided in the API and this actually makes sense (e.g. +400E+0,? so 400 for a tick size).? Looks like I'm on the right track.

So...? what's the consensus on the use the Decimal type?? There must be a reason why they are using this type now (potential huge numbers I suppose...).? Why just not use a long double?? How do people work with this type in practice?

Thanks,

Why can't you link your programs with the TWS API provided libraries? Those are the ones IBKR uses and has tested the API against. Using any "similarly named" libraries from source or Debian packages is guaranteed to invite trouble.

Not sure which API version you are using, but Version 10.17.01 (was the "latest" on 2022/08/09) ships with these libraries you should use:

source/CppClient/client/lib/biddll.dll
source/CppClient/client/lib/biddll.lib
source/CppClient/client/lib/eula.txt
source/CppClient/client/lib/libbid.lib

闯ü谤驳别苍

On Mon, Sep 19, 2022 at 08:11 PM, thepeete wrote:

the string received makes sense, but whatever is output by __bid64_from_string gives me monstrosity like 3584865303386914816 (in Hex: 0x31C0000000000000)

Not to mention, how exactly are you outputting the contents? After all, it is a binary encoding so looking at the hex or casting it to some other type doesn't make a lot of sense. In other words, wouldn't you want to use __bid64_to_string in order to output the actual value in a human readable format instead?

Can't say I have.

However, it's interesting to me that you downloaded the Intel library and built it from source yourself. Because... a quick internet search for "__bid64_from_string" yields . And, the accepted answer there shows that the library is being packaged by newer distributions. Indeed, in a debian-live-11.4.0-amd64 VM I see:

Package: libintelrdfpmath-dev                                                                      
Version: 2.0u2-4                                                                                   
State: not installed                                                                               
Priority: optional                                                                                 
Section: libdevel                                                                                  
Maintainer: Christian Stalp <chris@...>                                                   
Architecture: amd64                                                                                
Uncompressed Size: 73.4 M                                                                          
Description: Intel Decimal Floating-Point Math Library                                             
 Software implementation of the IEEE 754-2008 Decimal Floating-Point Arithmetic specification,     
 aimed at financial applications, especially in cases where legal requirements make it necessary   
 to use decimal, and not binary floating-point arithmetic (as computation performed with binary    
 floating-point operations may introduce small, but unacceptable errors).                          
Homepage: https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library      
Tags: devel::library, role::devel-lib

So I'm wondering if something went wrong with your custom build? Did you try installing "libintelrdfpmath-dev" from official repos and linking against that instead? Or... maybe you're not using Debian? In which case I wonder if there are RPMs available? Or maybe even the distribution packages are also broken.

-Just curious

Hi,

I'm trying to revive my old linux C++ program that connects to TWS, updating it use IBJts.10.16 (and now .18).? That Decimal type is really messing with me.? I can't link my program with the libraries included with the API, but I was able to download the Intel library and compile it with:

make CC="gcc -fPIC" CALL_BY_REF=0 GLOBAL_RND=0 GLOBAL_FLAGS=0 UNCHANGED_BINARY_FLAGS=0

The -fPIC was necessary for linking.? I am using gcc 12.1.1 20220730

Now my program compiles and links fine, seems to run just fine, except when getting "Decimal" data (e.g. a tick size), I get nonsensical numbers.? As far as I can see, the string received makes sense, but whatever is output by __bid64_from_string gives me monstrosity like 3584865303386914816 (in Hex: 0x31C0000000000000)

Did anybody encountered issues like me with the library?

joanmarcel119, you are my hero!? Thank you SO MUCH for taking the time to provide your thoughts.? Problem solved!!!