Thanks for the reply. I found the root cause of this.
I used ‘reqAllOpenOrders’ instead of ‘reqOpenOrders’ and that does not receive the ‘orderBound’ callback.
The confusing thing is that it seems that only on new orders that were submitted in TWS after a last API call to ‘reqOpenOrders’ the orderId is 0 when you retrieve via ‘reqAllOpenOrders’ later. On orders that were submitted before a last call to ‘reqOpenOrders’,
even when you retrieve them via ‘reqAllOpenOrders’ later, still a valid (negative) orderId is returned.?
The API doc indeed only mentions the orderBound callback for ‘reqOpenOrders’ and says to use ‘reqAllOpenOrders’ to ‘obtain those orders created via the API regardless of client application’. So while it does retrieve orders from TWS also, their orderId will
be zero if not bound prior.
Bart
On Mar 27, 2022, 1:28 PM -0700, 闯ü谤驳别苍 Reinold via groups.io <TwsApiOnGroupsIo@...>, wrote:
toggle quoted message
Show quoted text
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.
闯ü谤驳别苍
