Keyboard Shortcuts
Likes
- Twsapi
- Messages
Search
Re: One cancels all : Group contains orders for Personal Account
开云体育I had the exact thing.The issue is that one of your orders has the keyword "account="? specified and one does not.?? -------- Original message -------- From: hadry.hamza@... Date: 2024-09-29 10:48?a.m. (GMT-05:00) Subject: [TWS API] One cancels all : Group contains orders for Personal Account Hello, I get this error while creating the trail and the stop order using the one cancels all logic (OCA), it's working fine in the paper account but not in the live account, below is the error message:
What can be the issue here please ? oca_group_name = str(uuid.uuid4())
|
One cancels all : Group contains orders for Personal Account
Hello, I get this error while creating the trail and the stop order using the one cancels all logic (OCA), it's working fine in the paper account but not in the live account, below is the error message:
What can be the issue here please ? oca_group_name = str(uuid.uuid4())
|
Re: Any updated TWS API C++ library?
In my opinion, you are going to have to build it yourself. I was in the same boat when I started and chose to use C++. At first I tried putting it off and hoped to piggy back off someone else's repository, but ultimately it was a waste of time and I just accepted I needed to figure it out on my own and make my own shippable client repository with Cmake. There is a good amount of stuff on here about that. A lot of people helped me get my build going to use with linux. If you search by 'C++' and/or 'Cmake' you may find some helpful topics/threads. But it's going to be a tough, long road. I would advise starting on that just right away and cut your losses on trying to find something like this. Just my opinion, but it does come from experience.
?
Obviously, start with what you are hoping to accomplish. What parts of the API do you need, etc. Then at first only fill in the abstract virtual functions/callbacks for what you need, and build on top of it as your needs expand in your inherited EWrapper client main class. With inspiration from this board,? I made the client a smart pointer and any new strategies/repos/projects I want to run a strategy from, I start with my control center class as accepting that smart pointer in my constructor. I then have public functions from the smart pointer I can call that request things and I have getters/setters etc. for retrieving private members from my ib client. You know, the works. My client has a evolved a lot, but now it really has everything I figured a repo online would have that I could piggyback off of. The entire process has made me a much better developer and I learned so many new skills like bash development, Cmake, and learning that abstractions are not actually saving you in most instances. In reality, they are just adding more complexity to your projects by adding things you do not understand.
?
That's just my 2 cents, but what do I know. I'm just a guy on the internet. Good luck. |
Any updated TWS API C++ library?
Hi all,
?
I am building a trading model in C++. TWS API is not easy to use so I am looking for a helpful library that abstracts away many low level details and ease the development process. Google suggested me this library which was used in this video too. BUT the repo has not been updated in the last 8-9 years. Are there any actively updated C++ library repo for TWS API?
Thank you in advance! |
Re: All or None order for multi-leg options trades
Even if you can submit all orders at the same time you won't have a guarantee that all get filled at the same time. If you are concerned about available margin you could first calculate that and only place all your orders once you are convinced that it won't be an issue. |
Re: Time of order submission
You are correct. A better name for the Order quantity field would probably be "current quantity" or "remaining quantity". IBKR automatically decrements the field value after each partial fill. Or in case of child orders in a Bracket Order, IBKR will automatically sets quantities for all child orders to the actual fill quantity of the parent . And your client application can adjust the value at any point in time, too (up or down). If you need the original order quantity for orders at time of placement, you need to persist that information within the scope of your client application. Or if you want to avoid having to save state, you can use the OrderRef field as I had pointed out before. It is perfectly fine if you define a few context fields, encode them, for example, as a Json string, and store that string in the OrderRef field of the order. The OrderRef field description is best summarized in the Execution class as:
For the special case where your client applications do not change the order quantity after order placement, you can reconstruct the original order quantity from the orderStatus() callback. Each time you receive an orderStatus() update, it provides the actual "filled" and "remaining" quantities at that point in time. 闯ü谤驳别苍 ? ? On Fri, Sep 27, 2024 at 06:40 PM, Jesse Stone wrote:
|
Re: Time of order submission
Thanks very much for this information. That makes sense. I just wanted to be sure I was not missing something. It appears that the total number of shares of the order is missing also? There is "TotalQuantity", but that appears to be the shares remaining to be filled, rather than the total requested, and it drops to zero if the order is cancelled, such that one cannot recover the original number of shares requested from the information provided. I guess I need to keep track of all such quantities myself, but please let me know if my understanding of "TotalQuantity" is not correct. Thanks again very much for your help. |
All or None order for multi-leg options trades
What is the best way to implement a multi-leg options strategy using the TWS API? Basically, all of the legs in the strategy should immediately execute or none of them should. Placing orders for each leg one by one can result in some of the legs not executing due to margin issues. So, I want all of the orders to get rejected in case of insufficient margin.? Thanks in advance for your response.?? |
Re: Time of order submission
I guess when you think about it, “time of order placement” is not really an Order attribute, so I would not expect to find such a field in the Order class. Just like “time of order execution” is not an Order? attribute but that of one or more Executions. Consequently, order execution times are recorded and reported in Execution objects. TWS API has no equivalent to Execution for order placement and I am not sure that there needs to be one. Your client application can easily record the time of order placement, either when it makes the placeOrder request or, probably more appropriately, when it receives the first OrderState/OrderStatus update callbacks from TWS/IBGW. That way you can also record order placement times for orders placed through TWS or other means. That way, you could also record other order related events such as when orders actually become active (like child orders in brackets or conditional orders), when orders change (such as trailing price orders), or when any other relevant order state changes take place. You may be able to get Order Time from FlexQueries, but I have not tried this and the approach resembles more batch processing than a quick request/response call. And finally, you could use the OrderRef string field, to tag your order with any custom information and in any format you’d prefer. I know that some of our members tag their orders with comprehensive context information, and order placement time could be one those context items. This approach has the advantage that your custom OrderRef string is reported back to your client application by any and all TWS API callbacks that have an Order parameter. 闯ü谤驳别苍 ? On Thu, Sep 26, 2024 at 01:16 PM, Jesse Stone wrote:
|
Time of order submission
When I ask TWS API for a list of the orders that I have placed recently, I get back a number of attributes of each order (PermId, Action, LmtPrice, etc.)
However, the order placement time does not appear to be here, which seems odd. Am I correct in thinking that TWS API is not able to tell me the time at which I placed orders, and thus it is up to me to keep track of those times? Or am I missing something? It seems odd that time of order placement would not be among the order attributes that TWS API reports to me. |
Re: API/CTCI orders for canadian stocks are not allowed error message
Since you were able to trade the Canadian stocks using the API I called up the tech support one more time. He assured me that no Canadian product will be allowed to be traded through the API. He also told me that if you are currently able to trade then you won’t won’t eventually be able to trade. He also confirmed that this rule is applied to all Canadian products not just stocks . You can trade by hand but not using their API. |
How many reqHistoricalData requests with keepUpToDate=true can be run in parallel
Gents,
Is there a limit on how many historical data requests (reqHistoricalData call) with keepUpToDate=true can be run in parallel?
Also, if for the same security I request historical data (with keepUpToDate=true) of various bar sizes, does each bar size count to the limit, or only one "slot" is used? |
Re: API/CTCI orders for canadian stocks are not allowed error message
Can you be more precise about what you think that will no longer be possible? I usually do not work with instruments in Canada, but a few quick market BUY orders for ADN@TSE and ABRA@VENTRURE in a paper account worked just fine both SMART and direct routed. They properly show up as CAD positions in TWS. If I am not mistaken, TSE and VENTURE are the two TSX exchanges. The two symbols were randomly picked from the top of the TSX listings. 闯ü谤驳别苍 ? ? On Thu, Sep 19, 2024 at 01:23 PM, nkulki wrote:
|
Error Code -> 366 w/ reqHistoricalData() in ib_insync for realtime stream
Hi,
?
Anyone else seeing this error start popping up today? Only started since about 3 P.M. The contract is valid and has been working since this morning. This is through ib_insync and is using callbacks with self.ib.run() following the call below catching event updates. Here is the following error:
?
reqHistoricalData: Timeout for Future(conId=563947733, symbol='NQ', lastTradeDateOrContractMonth='20241220', multiplier='20', exchange='CME', currency='USD', localSymbol='NQZ4', tradingClass='NQ')
Error 366, reqId 5: No historical data query found for ticker id:5, contract: Future(conId=563947733, symbol='NQ', lastTradeDateOrContractMonth='20241220', multiplier='20', exchange='CME', currency='USD', localSymbol='NQZ4', tradingClass='NQ') ?
Call:
bars = self.ib.reqHistoricalData(
self.contract,
endDateTime='',
durationStr='1 D',
barSizeSetting='5 mins',
whatToShow='Trades',
useRTH=False,
formatDate=1,
keepUpToDate=True
)
#event handler for updates to realtime historical OHLC data...
bars.updateEvent += self.OnBarUpdate
? |
Re: How are built the Continuous future data retrieved with secType = CONTFUT ?
TL;DR Volume-based ratio adjustment
?
TWS shows the adjustment on the Chart. For example, let's take CME Crude Oil (CL). On 14 Aug there is a small marker "RA 101.63%" being shown on the TWS chart with CL CONTFUT. I guess RA = Ratio Adjustment. This is shown if you enable "Cash Dividend Indicator" in chart settings. Basically I think they simplified it and handle it exactly like for dividends - not that it makes it more clear as they also do not explain how it's calculated for dividends either. Coincidentally 14 Aug was the volume rollover day. |