¿ªÔÆÌåÓý

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

TWS API GUI

 

Hello All,

I have a C# application working for years.
I am considering using the GUI features to see if I can plot / create my own charts. Is that possible? Does anyone have experience doing / attempting this?

I am considering using 1-2 symbols to create custom charts using?tick data.

Cheers,

TraderAPI


Re: TWS order has reqId=0; how to cancel it from API?

 

What does it mean when you say "I can see this order in the API"?

The section of the API reference describes the various options you have When client 0 calls or? ? callbacks will provide mappings of permIds to orderIds client 0 can use to manipulate orders that were placed by other clients or manually in TWS. You can configure TWS such that negative orderIds are used to better separate these orders them from orders your API client places.

For this to work, orders must be "open" from the TWS point of view. I am not sure whether simulated orders with status "pre-submitted" are considered "open" for the purpose of order binding, but you should be able to quickly try and and see whether you get an ?callback.

´³¨¹°ù²µ±ð²Ô


TWS order has reqId=0; how to cancel it from API?

 

I have a manual order placed in TWS.
I can see this order in the API (my API client is set to clientID=0).
It shows as:
order=Order(permId=390120308, action='BUY', totalQuantity=10.0, orderType='STP LMT', lmtPrice=25.0, auxPrice=24.5, tif='GTC', ocaType=3, displaySize=2147483647, rule80A='0', trailStopPrice=24.5, openClose='', volatilityType=0, deltaNeutralOrderType='None', deltaNeutralOpenClose='?', referencePriceType=0, account='XXXX', clearingIntent='IB', adjustedOrderType='None', cashQty=0.0, dontUseAutoPriceForHedge=True)

Now I want to cancel this order from the API.
When I pass this order to cancelOrder(order), the following error shows:
Error 10147, reqId 0: OrderId 0 that needs to be cancelled is not found.

Indeed, while there is a permId, order.clientId and order.reqId are 0.

How can I cancel this order?

Note: this order has status pre-submitted on TWS because it is a stop limit order for a CBOE combo order position, and thus it is held by IB until the stop triggers as stop limit is not natively supported by CBOE.


Re: Install TWS or IB gateway on Ubuntu and ARM64 bit processor

 

Hello

Have you found a way to make it work? I tried different distros and always got to the same point of being unable to install IB Gateway. I installed IB Gateway in a Debian VM and copied the resulting folder but it didn't work either, not even installing Oracle's JDK1.8.0_321.


Locked Re: Paid engagement for python script

 

Please folks if you want to follow up on this request, reply directly to the poster.

I'm locking this topic now.

Richard King Moderator


Locked Re: Paid engagement for python script

 

¿ªÔÆÌåÓý

Hey Matt-

I¡¯m interested in this project as well. ?I¡¯m currently managing a multi strategy long/short portfolio via IBApi overseeing 7 figures in assets, much of it being outside funds. ?Let me know if you need other qualifications or if you¡¯d like a price estimate.

Thanks,

Mike

On Mar 26, 2022, at 3:29 PM, mfleharty@... wrote:

?
Hi,?
I'm writing to see if anyone is interested in 1) a paid engagement to develop a python script, functionality described below; and 2) spending the time to help me understand the logic behind the python script execution.? ??
?
Desired functionality:? When a new order is placed, that order will be either extremely above or below the current bid/ask spread, and the order is being used simply as a flag.??
For example, a limit buy order for 1 share of MSFT at $100 is submitted.? At that point, I'd like the python script to:?
1) detect that the order has been submitted;
2) cancel the order;
3) submit an option call order for symbol MSFT at a strike price that is just OTM, at the soonest expiration date.? ?
4) Exit strategy: detect when an order on the opposite side has been submitted (for example, sell 1 share of MSFT at $500)
4a) delete the sell order
4b) if the call order has been filled, exit the option position
?
The opposite of the above scenario needs to work as well, with a sell order and puts.?
?
Additionally, I'd ask the programmer to allot 4hrs to explain the execution of the code and allow for questions in order for me to understand the script, so that I can maintain/modify going forward.? I do have programming experience, but it is in classic ASP.? ??
?
Sample script execution (assume current price of MSFT stock is $300, and assume current date is 3/28/2022):
1) outside of the python script, a limit buy order is submitted for 1 share of MSFT at $100/share
2) the python script deletes this order
3) python script submits an order for 1 MSFT Call option at the Ask, with a strike price of $302.5, expiring on 4/1/2022
4) outside of the python script, a limit sell order is submitted for 1 share of MSFT at $500/share
5) the python script deletes this order
6) python script exits or cancels the existing/open call position at the Bid price
7) python script submits an order for 1 MSFT option Put at the Bid, with a strike price of $297.5 expiring on 4/1/2022
8) At 3:55 PM EST, the python script closes all positions.??
?
Notes:??
1)??Soonest expiration date must account for weeklies, for example M/W/F in the case of SPY.?
2)? Stock symbol must be variable.??
3)? I believe Symbol + Order Type (buy/sell) can be used as a flag.? The order price will not be static, therefore I don't think it can be used as part of the flag.??
?
Please email?mfleharty@...?if interested.? Thanks in advance.
Matt


Locked Re: Paid engagement for python script

 

¿ªÔÆÌåÓý

You may want to check first if IB lets you submit orders that are so far away from market price. I believe they have a limit on accepting limit orders that are too far away from current bid/ask depending on the instrument type and exchange.?
If your trigger is to be based on the underlying reaching a certain price, you could handle it via a conditional order in the script so then you don¡¯t need an external flag.

rgds, Bart
On Mar 26, 2022, 12:43 PM -0700, RobDawg35 via groups.io <rob.sandberg26@...>, wrote:
I can do this?

Let me know,
Rob?

On Sat, Mar 26, 2022 at 3:29 PM <mfleharty@...> wrote:
Hi,?
I'm writing to see if anyone is interested in 1) a paid engagement to develop a python script, functionality described below; and 2) spending the time to help me understand the logic behind the python script execution.? ??
?
Desired functionality:? When a new order is placed, that order will be either extremely above or below the current bid/ask spread, and the order is being used simply as a flag.??
For example, a limit buy order for 1 share of MSFT at $100 is submitted.? At that point, I'd like the python script to:?
1) detect that the order has been submitted;
2) cancel the order;
3) submit an option call order for symbol MSFT at a strike price that is just OTM, at the soonest expiration date.? ?
4) Exit strategy: detect when an order on the opposite side has been submitted (for example, sell 1 share of MSFT at $500)
4a) delete the sell order
4b) if the call order has been filled, exit the option position
?
The opposite of the above scenario needs to work as well, with a sell order and puts.?
?
Additionally, I'd ask the programmer to allot 4hrs to explain the execution of the code and allow for questions in order for me to understand the script, so that I can maintain/modify going forward.? I do have programming experience, but it is in classic ASP.? ??
?
Sample script execution (assume current price of MSFT stock is $300, and assume current date is 3/28/2022):
1) outside of the python script, a limit buy order is submitted for 1 share of MSFT at $100/share
2) the python script deletes this order
3) python script submits an order for 1 MSFT Call option at the Ask, with a strike price of $302.5, expiring on 4/1/2022
4) outside of the python script, a limit sell order is submitted for 1 share of MSFT at $500/share
5) the python script deletes this order
6) python script exits or cancels the existing/open call position at the Bid price
7) python script submits an order for 1 MSFT option Put at the Bid, with a strike price of $297.5 expiring on 4/1/2022
8) At 3:55 PM EST, the python script closes all positions.??
?
Notes:??
1)??Soonest expiration date must account for weeklies, for example M/W/F in the case of SPY.?
2)? Stock symbol must be variable.??
3)? I believe Symbol + Order Type (buy/sell) can be used as a flag.? The order price will not be static, therefore I don't think it can be used as part of the flag.??
?
Please email?mfleharty@...?if interested.? Thanks in advance.
Matt


Locked Re: Paid engagement for python script

 

I can do this?

Let me know,
Rob?

On Sat, Mar 26, 2022 at 3:29 PM <mfleharty@...> wrote:
Hi,?
I'm writing to see if anyone is interested in 1) a paid engagement to develop a python script, functionality described below; and 2) spending the time to help me understand the logic behind the python script execution.? ??
?
Desired functionality:? When a new order is placed, that order will be either extremely above or below the current bid/ask spread, and the order is being used simply as a flag.??
For example, a limit buy order for 1 share of MSFT at $100 is submitted.? At that point, I'd like the python script to:?
1) detect that the order has been submitted;
2) cancel the order;
3) submit an option call order for symbol MSFT at a strike price that is just OTM, at the soonest expiration date.? ?
4) Exit strategy: detect when an order on the opposite side has been submitted (for example, sell 1 share of MSFT at $500)
4a) delete the sell order
4b) if the call order has been filled, exit the option position
?
The opposite of the above scenario needs to work as well, with a sell order and puts.?
?
Additionally, I'd ask the programmer to allot 4hrs to explain the execution of the code and allow for questions in order for me to understand the script, so that I can maintain/modify going forward.? I do have programming experience, but it is in classic ASP.? ??
?
Sample script execution (assume current price of MSFT stock is $300, and assume current date is 3/28/2022):
1) outside of the python script, a limit buy order is submitted for 1 share of MSFT at $100/share
2) the python script deletes this order
3) python script submits an order for 1 MSFT Call option at the Ask, with a strike price of $302.5, expiring on 4/1/2022
4) outside of the python script, a limit sell order is submitted for 1 share of MSFT at $500/share
5) the python script deletes this order
6) python script exits or cancels the existing/open call position at the Bid price
7) python script submits an order for 1 MSFT option Put at the Bid, with a strike price of $297.5 expiring on 4/1/2022
8) At 3:55 PM EST, the python script closes all positions.??
?
Notes:??
1)??Soonest expiration date must account for weeklies, for example M/W/F in the case of SPY.?
2)? Stock symbol must be variable.??
3)? I believe Symbol + Order Type (buy/sell) can be used as a flag.? The order price will not be static, therefore I don't think it can be used as part of the flag.??
?
Please email?mfleharty@...?if interested.? Thanks in advance.
Matt


Locked Paid engagement for python script

 

Hi,?
I'm writing to see if anyone is interested in 1) a paid engagement to develop a python script, functionality described below; and 2) spending the time to help me understand the logic behind the python script execution.? ??
?
Desired functionality:? When a new order is placed, that order will be either extremely above or below the current bid/ask spread, and the order is being used simply as a flag.??
For example, a limit buy order for 1 share of MSFT at $100 is submitted.? At that point, I'd like the python script to:?
1) detect that the order has been submitted;
2) cancel the order;
3) submit an option call order for symbol MSFT at a strike price that is just OTM, at the soonest expiration date.? ?
4) Exit strategy: detect when an order on the opposite side has been submitted (for example, sell 1 share of MSFT at $500)
4a) delete the sell order
4b) if the call order has been filled, exit the option position
?
The opposite of the above scenario needs to work as well, with a sell order and puts.?
?
Additionally, I'd ask the programmer to allot 4hrs to explain the execution of the code and allow for questions in order for me to understand the script, so that I can maintain/modify going forward.? I do have programming experience, but it is in classic ASP.? ??
?
Sample script execution (assume current price of MSFT stock is $300, and assume current date is 3/28/2022):
1) outside of the python script, a limit buy order is submitted for 1 share of MSFT at $100/share
2) the python script deletes this order
3) python script submits an order for 1 MSFT Call option at the Ask, with a strike price of $302.5, expiring on 4/1/2022
4) outside of the python script, a limit sell order is submitted for 1 share of MSFT at $500/share
5) the python script deletes this order
6) python script exits or cancels the existing/open call position at the Bid price
7) python script submits an order for 1 MSFT option Put at the Bid, with a strike price of $297.5 expiring on 4/1/2022
8) At 3:55 PM EST, the python script closes all positions.??
?
Notes:??
1)??Soonest expiration date must account for weeklies, for example M/W/F in the case of SPY.?
2)? Stock symbol must be variable.??
3)? I believe Symbol + Order Type (buy/sell) can be used as a flag.? The order price will not be static, therefore I don't think it can be used as part of the flag.??
?
Please email?mfleharty@...?if interested.? Thanks in advance.
Matt


Re: Issue retrieving delayed frozen data with recent TWS version (>= 9.74)

 

Same problem here. I already opened a ticket to IB, but no response yet.


Issue retrieving delayed frozen data with recent TWS version (>= 9.74)

 

Hello,

Just be aware that TWS API has an issue regarding delayed market data requests (when you don't have real time subscriptions for the specificied instruments)
It was working fine until TWS 9.73 but it doesn't work as expected anymore.

Here are 2 snapshots, the first one has been generated using TWS 9.81 (where we don't received delayed market data / no bid & ask received for most options)
Whereas it works fine using TWS 9.73 (second snapshot)

Similiar tests have been conducted by different users on various workstations with similar behavior.





Re: TWS 50/sec limit

 

Hi Franck;

Definitely, something happened with introduction of the PACEAPI feature (9.73 -> 9.74)
We've got some weird behavior with the more recent versions of TWS (> 9.73)
That's why we still use TWS 9.73 (which is very stable) but it will be decommissioned on 31th March 2022. (It will cause us a lot of trouble)

Just to give another example, about pacing issues.
When you send requests for delayed market data for a significant number of options (for which you don't have realtime subscription)

If you launch 50 requests at rate of (1 request every 50 ms); It works perfectly well with TWS 9.73
But with most recent versions of TWS; you receive data for only a subset of these instruments.
If you increase the delay between your requests, you get more responses:
At the extreme, if you wait 2 seconds between each request; it works correctly and you receive delayed market data for all the options.
But it means you retrieve the data at a very low rate...

TWS is globally a great platform and IB Services are very good. But I don't understand? that IB has not been able to address this issue. We've opened our first ticket about it more than 2 years ago...
It drives me nuts. I spent so many time explaining the case, creating tickets, providing them with samples ....?

Loic


Re: Bracket sequences not executing and a new state - Transmitted, not acknowledged.

Nick
 

¿ªÔÆÌåÓý

There have been several reports here of broken features in the TWS 10 series. Seemingly unrelated errors are happening and it feels like TWS has gotten away from them in the 10 series.

Hanging on to the 9 series as long as possible seems like the best option for now.


On 3/25/2022 6:43 PM, mark collins wrote:

Just to update in case anyone else has whack executions with 10.14. I moved to 9.83i (which is apparently still supported) and the strange statuses, the loss of bracket components and similar garbage stopped occurring. Over the last two days that whole experience? cost several thousand dollars through unbalanced trades and execution failures on requested bracket exits. Be careful, folks, IB can certainly bring fresh surprises when moving between versions.

Best wishes,

M


On Thu, 24 Mar 2022 at 17:49, mark collins via <mark.collins=[email protected]> wrote:
Hello,

I'm trying to investigate why some of my accounts are executing differently on 10.12 versus 10.14.1e. The symptom is that the first in a sequence of bracket orders is executed on both (parent order fills and sets the bracket), but on 10.14 all subsequent orders just sit awaiting execution. On 10.12 they are executed in as expected. I've used the same bracket order execution code for about 4 years, since 9.72, perhaps the spec has changed in some way? It's the standard bracket construction as defined in the TWS guide - layer the trades under the parent id with transmit = false and then the last order with transmit set to true. I've got live accounts on TWS 10.14 so if it's broken I need to move back (there was a reason why I stuck with 9.72 for so long - it was at least old enough to be tested thoroughly!).

I don't know if this is related but on paper accounts I'm also now seeing order statuses of "Transmitted not yet acknowledged" which is blocking orders until they expire (which does eventually clear them a long time after they are set to expire on the GTD). You can't cancel them, the trade time in force is unmodifiable (marked as "INVALID") and because they are potentially pending they screw with the order tracking. These are both new experiences with TWS.

All suggestions welcome,


M


--
+44 (0) 7528 551604?
Gulfstream Software - Winner Risk Management Awards 2010
This message is subject to :


--
+44 (0) 7528 551604?
Gulfstream Software - Winner Risk Management Awards 2010
This message is subject to :


Re: Bracket sequences not executing and a new state - Transmitted, not acknowledged.

 

Just to update in case anyone else has whack executions with 10.14. I moved to 9.83i (which is apparently still supported) and the strange statuses, the loss of bracket components and similar garbage stopped occurring. Over the last two days that whole experience? cost several thousand dollars through unbalanced trades and execution failures on requested bracket exits. Be careful, folks, IB can certainly bring fresh surprises when moving between versions.

Best wishes,

M


On Thu, 24 Mar 2022 at 17:49, mark collins via <mark.collins=[email protected]> wrote:

Hello,

I'm trying to investigate why some of my accounts are executing differently on 10.12 versus 10.14.1e. The symptom is that the first in a sequence of bracket orders is executed on both (parent order fills and sets the bracket), but on 10.14 all subsequent orders just sit awaiting execution. On 10.12 they are executed in as expected. I've used the same bracket order execution code for about 4 years, since 9.72, perhaps the spec has changed in some way? It's the standard bracket construction as defined in the TWS guide - layer the trades under the parent id with transmit = false and then the last order with transmit set to true. I've got live accounts on TWS 10.14 so if it's broken I need to move back (there was a reason why I stuck with 9.72 for so long - it was at least old enough to be tested thoroughly!).

I don't know if this is related but on paper accounts I'm also now seeing order statuses of "Transmitted not yet acknowledged" which is blocking orders until they expire (which does eventually clear them a long time after they are set to expire on the GTD). You can't cancel them, the trade time in force is unmodifiable (marked as "INVALID") and because they are potentially pending they screw with the order tracking. These are both new experiences with TWS.

All suggestions welcome,


M


--
+44 (0) 7528 551604?
Gulfstream Software - Winner Risk Management Awards 2010
This message is subject to :



--
+44 (0) 7528 551604?
Gulfstream Software - Winner Risk Management Awards 2010
This message is subject to :


Possible bug in TWS API when requesting auction price, volume, and imbalance data for ASX-listed securities

 

Hi,

When requesting auction price, volume, and imbalance data for ASX-listed securities in the pre-auction period, I'm getting the same number returned to me for both auction volume and auction imbalance, even though the tick type is different. I've put together an MWE to help anyone else look into this possible bug. I also just ran this MWE during the pre-close period today and I've pasted some of the output produced below so you can see what I mean. Anyway, the code is:
from ibapi.client import EClient
from ibapi.wrapper import EWrapper
from ibapi.contract import Contract
from ibapi.order import Order
from ibapi.order_state import OrderState

import threading
import time
from datetime import datetime
import queue
class IBapi(EWrapper, EClient):
def __init__(self):
EClient.__init__(self, self)
def request_auction_data_single(self, idnum: int, contract1: Contract):
self.reqMktData(idnum, contract1, 'mdoff,225', False, False, []) #225 is tick id for auction data of volume, price, and imbalance
return None
def tickPrice(self, reqId, tickType, price, attrib):
# tick price data sent by TWS is received by this function
attrib_as_string = str(attrib)
print("tickPrice triggered. reqId=%d, tickType=%d, price=%f, attribasstr=%s" % (reqId, tickType, price, attrib_as_string))
return None
def tickSize(self, reqId, tickType, size):
# tick size data sent by TWS is received by this function
print("tickSize triggered. reqId=%d, tickType=%d, size=%d" % (reqId, tickType, size))
return None
def error(self, id, errorCode, errorString):
errormessage = "TWS error. id = %d. errorcode = %d. msg = %s" % (id, errorCode, errorString)
print(errormessage)
def build_contract(self, mkt: str, scy: str, sectype: str, currency: str):
cc1 = Contract()
cc1.exchange = mkt
cc1.symbol = scy
cc1.secType = sectype
cc1.currency = currency
return cc1

def run_loop():
app.run()

app = IBapi()
app.connect("127.0.0.1", 7496, 0)

# Start the app in a thread
api_thread = threading.Thread(target=run_loop, daemon=True)
api_thread.start()

time.sleep(1) # Sleep interval to allow time for connection to server

# Request auction data
id1 = app.reqIds(-1)
contract1 = app.build_contract("ASX","NAB","STK","AUD")
app.request_auction_data_single(id1, contract1)


On my machine, this snippet will start printing auction price, volume, and imbalance data to the terminal for NAB (National Australian Bank) - which is one of the big banks listed on the ASX. I ran the snippet in the pre-close period today (just after 4pm Sydney time) and here is a snippet of the output produced:
tickSize? triggered. reqId=5, tickType=36, size=897951
tickPrice triggered. reqId=5, tickType=35, price=30.160000, attribasstr=CanAutoExecute: 0, PastLimit: 0, PreOpen: 0
tickSize? triggered. reqId=5, tickType=61, size=0
tickSize? triggered. reqId=5, tickType=34, size=912196
tickSize? triggered. reqId=5, tickType=36, size=912196
tickSize? triggered. reqId=5, tickType=34, size=915148
tickSize? triggered. reqId=5, tickType=36, size=915148
tickPrice triggered. reqId=5, tickType=35, price=30.290001, attribasstr=CanAutoExecute: 0, PastLimit: 0, PreOpen: 0
tickSize? triggered. reqId=5, tickType=34, size=915178
tickSize? triggered. reqId=5, tickType=36, size=915178
tickSize? triggered. reqId=5, tickType=34, size=915190
tickSize? triggered. reqId=5, tickType=36, size=915190
tickSize? triggered. reqId=5, tickType=34, size=916392
tickSize? triggered. reqId=5, tickType=36, size=916392
tickPrice triggered. reqId=5, tickType=35, price=30.250000, attribasstr=CanAutoExecute: 0, PastLimit: 0, PreOpen: 0
tickSize? triggered. reqId=5, tickType=34, size=916618
tickSize? triggered. reqId=5, tickType=36, size=916618
tickSize? triggered. reqId=5, tickType=34, size=917042
tickSize? triggered. reqId=5, tickType=36, size=917042
tickSize? triggered. reqId=5, tickType=34, size=917851
tickSize? triggered. reqId=5, tickType=36, size=917851
tickSize? triggered. reqId=5, tickType=34, size=917863
tickSize? triggered. reqId=5, tickType=36, size=917863
My understanding is that tickType 34 is supposed to be the volume, and tickType 36 is the imbalance. However, as can be seen here, they are both returning exactly the same number each time. Note, I've verified this behaviour across multiple securities on multiple days.

Cheers all, any help would be most appreciated.

Colin


Re: TWS 50/sec limit

 

"@Frank: that's exactly the same as I'm doing it, but I'm still getting the pace violation error."

My code is MVSC C++ and my api code uses the winsock2 send function, so I know exactly when the message is sent to TWS.? It's worked with several different TWS versions.? The 1015 ms value came through trial & error, but has been rock solid.? Do you know for sure your api code is sending the message when you call it?


Re: TWS 50/sec limit

Nick
 

You need to enable the api log to see when TWS thinks the requests arrived. Your requests may not arrive at TWS at the time when you send them.

On 3/24/2022 4:56 PM, hansblafoo via groups.io wrote:
EDIT: I just made a test and I'm pretty sure that it is a bug within the TWS or the TWS API. I'm printing the time of every request sent to server and I can clearly see that I never pass the 50 msg/sec limit.


Re: TWS 50/sec limit

 

Nick, I guess that after 6 years since the original post was written, the OP doesn't care anymore. ;-) I just hijacked the thread for asking another question regarding the 50 msg/sec limit instead of opening a new one.

@Bob: I also tried your approach but when I'm requesting option chains and their data (option contract details, option prices) I still get the pace violation error. I absolutely don't have a clue why this is happening, but I'll investigate it.

@Frank: that's exactly the same as I'm doing it, but I'm still getting the pace violation error.

@´³¨¹°ù²µ±ð²Ô: thanks for providing a link, that clarifies my question. I also know this connection configuration for activating the internal pacing prevention. However, as I'm currently using an older TWS release (because of the issue requesting delayed data which only works properly in TWS releases prior 9.73), I cannot use it. Maybe it's a bug within this older TWS release.

EDIT: I just made a test and I'm pretty sure that it is a bug within the TWS or the TWS API. I'm printing the time of every request sent to server and I can clearly see that I never pass the 50 msg/sec limit. However, I just got a message that I've exceeded it by sending 180 (!) msg/sec. This cannot be true. Thus, it may be a problem with my old TWS release but nevertheless it's the only one working with delayed data. Btw, I already reported the delayed data bug to IB but still I got no response.


Bracket sequences not executing and a new state - Transmitted, not acknowledged.

 

Hello,

I'm trying to investigate why some of my accounts are executing differently on 10.12 versus 10.14.1e. The symptom is that the first in a sequence of bracket orders is executed on both (parent order fills and sets the bracket), but on 10.14 all subsequent orders just sit awaiting execution. On 10.12 they are executed in as expected. I've used the same bracket order execution code for about 4 years, since 9.72, perhaps the spec has changed in some way? It's the standard bracket construction as defined in the TWS guide - layer the trades under the parent id with transmit = false and then the last order with transmit set to true. I've got live accounts on TWS 10.14 so if it's broken I need to move back (there was a reason why I stuck with 9.72 for so long - it was at least old enough to be tested thoroughly!).

I don't know if this is related but on paper accounts I'm also now seeing order statuses of "Transmitted not yet acknowledged" which is blocking orders until they expire (which does eventually clear them a long time after they are set to expire on the GTD). You can't cancel them, the trade time in force is unmodifiable (marked as "INVALID") and because they are potentially pending they screw with the order tracking. These are both new experiences with TWS.

All suggestions welcome,


M


--
+44 (0) 7528 551604?
Gulfstream Software - Winner Risk Management Awards 2010
This message is subject to :


Re: bunch of reqMktData requests for options

 

Hi all,

Not sure IB will address this issue soon enough (see their reply below)
I'm upset and frustrated as I raised my first ticket about it more than 2 years ago;

---------------------

Dear Sir,

I haven't received an update from the development team, but I have asked for updates or progress reports. Please keep in mind, because this concerns delayed data and not live data, our developers might not view it as the most urgent, and for that I apologize. I will continue to ask for updates so they may review this further, and will let you know of any updates as soon as I have them.
Regards,
xxx
IBKR API Support