¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Starting with TWS APi using C++, looking for advice


 

I'm just getting started with using the TWS APi.? I'm using c++ as that's the language I'm most familiar with.
Questions:
1) Is it better for me to use the latest APi version 9.81 or the stable version 9.76 ?
2) Should I use the TWS APi library provided by IB, or should I try using the TWSApiC++ library (at?) ?

My goal is to be able to get my account balance, view current positions and submit/cancel/change/track orders.
Thanks.


 

¿ªÔÆÌåÓý

Hi,
  1. I think it doesn't matter much. But I am using 9.76. It is pretty stable. Unless you need the need features in the new version, you don't need to use it.
  2. I used to use TWSApiC++. But I believe it is a little bit out-date and not maintained any more. So I switched to use the c++ library provided by IB. It is much easier if IB has any upgrade.?


From: [email protected] <[email protected]> on behalf of ron.hardock@... <ron.hardock@...>
Sent: Wednesday, January 13, 2021 12:27 AM
To: [email protected] <[email protected]>
Subject: [TWS API] Starting with TWS APi using C++, looking for advice
?
I'm just getting started with using the TWS APi.? I'm using c++ as that's the language I'm most familiar with.
Questions:
1) Is it better for me to use the latest APi version 9.81 or the stable version 9.76 ?
2) Should I use the TWS APi library provided by IB, or should I try using the TWSApiC++ library (at?) ?

My goal is to be able to get my account balance, view current positions and submit/cancel/change/track orders.
Thanks.


 

Regarding 2, I use TWS API. I can't remember why I didn't opt the second.

Cancelling/changing and tracking orders is a little bit more difficult. Modifying orders () necessitates you remembering all the order IDs. To modify order with id, say 300, you just submit another order using the same id: 300. Some fields you will be able to revise (e.g. price), others you won't.

If you're continuously revising passive limit orders, you'll need to keep all of these ids in some container, and then remove them when you get fill information back, taking care never to use any id more than once.

I remember a few things about it:

1.) revising orders seemed to be much quicker than cancelling and re-sending an order. This was my experience just by visually assessing performance on TWS GUI.

2.) I was always ending up with occasional errors, telling me that that order had already been filled or cancelled. I was always quite suspicious of the order info data feed. For instance, if IB doesn't trigger execDetails() fast enough to tell you about a fill, and you send off a revision, then you'll get a delayed error. I was being an idiot though, and trying to peg a limit buy at a tick below the best bid.

Conceivably you would have to deal with partial fills, too, but I personally was only trading a contract at a time for Eminis.?

3.) I was always ending up with "bad" fills, and had difficulty reconciling backtest behavior and live/paper trading behavior. I was always quite suspicious of the price/order data feed as well. For example, if your order data feed is delayed a little, and you're trying to peg orders to the best bid/ask, then you're probably not actually pegged. You tend to get filled faster for overly-ambitious orders, and not filled for too under-ambitious orders.

I gave up on this particular strategy, and moved to market orders, not keeping track of ids, and just incrementing the order id by 1 every time.


 

about #1:

- I use latest 9.81 and I recommend using latest
a- Increment is marginal so few reason it failed and it secure your code, see also response to #2
b- It's more stable and better to get info about "shorting" capabilities (return amount instead of advice

?

about #2

Are you fluid un c++ ? If yes then go for native IB API, if no ... go for becoming fluid first. (or use IB REST API but NOT TWS)

- TwsApiCpp is build atop and one day or another you will need to dig in the IB APi anyway.

- The thing that you need to know in c++ is how to use ::mutex and ::thread. that's it.

?

But what mention as what you aim for, doesn't even need full real-time multithread. IB Api does answer reasonably quickly. (Way faster than REST in general and far better concept of "subscribe")

For "Balance and account" I suggest you consider the IB REST API instead of TWS API, but just for simple matter like that, Be careful that if you deal with orders your prone to enter a different world of complexity, as you will most probably need to get latest Bid/Ask etc ... and this is here lies the issues

?

?