--- In twsapi@y..., Nick <nickrbox@o...> wrote:
It looks like when you ask for open orders when there are no open
orders
TWS simply doesn't bother to send a reply. At least it stayed idle
for 15
seconds when I tried it.
Hehe, you are in for a BIGGER surprise. Here's the ACTUAL behaviour.
If there are open orders when you start, that request will pass them
on to you. The orderId will always be different than any you have
stored for them, be prepared, new id's, its up to you to figure out
where they fit with what you sent before. The open order callback
doesn't include the PermId stuff, so you cant relate then to the
persistent id's.
Then the fun. After the first time, it never works again, so you
better keep good track of your orders, you cant just go 'oh heck, i'm
confused, lets fetch the definitive list from the broker'. It only
works to give you the list of the orders already there when you
started, after that, its up to you to track them, and lord help you
if there is a communication error, cuz IB certainly wont.
The only way i found to use this info reliably, was like this. At
startup, i request the open order list, then I promptly cancel each
of them as it reports them back.
After I am sure all orders are cancelled, I proceed to look into my
data, and see what orders I _should_ have in, and place new ones.
Then after that, at any point, if your code even suspects a
communication problem, look out, you are probly headed to duplicate
Id city, unless you cancel all the outstanding orders, request a new
block of Id's, and start the logic over again.
The application we put into testing today, is not a heavy trader by
any stretch. For each round trip, it does a total of 3 orders, one
for entry, one for target, one for stop, the stop trails, so it may
be modified a bunch enroute. We did a tad under 100 round trips with
it today (97 i beleive), and there were no screw ups. That would be
a total of 300 or so orders actually placed and processed, I dont
know how many entries were missed, and i'm to lazy tonite to go thru
the journal and count them.
I'm not here to whine about how it's broken though, my clients pay me
to provide solutions, not problems. The commission structure at IB
is attractive enough to one of our applications, that the customer is
willing to pay for the effort to 'get it right'. We've got a lot of
workaround code in place, and the overall package is getting pretty
solid now, the tidbit i got here yesterday was the ticket. It is
possible to resynch with IB if you do all your own socket code, and
you can actually close the socket and restart.
We ran all day today, program trading one futures contract on the
pretend account. Tomorrow the next test, 2 contracts (nq and es)
with size 5, and hopefully we'll see partials thru the day. I'm not
impressed with the api, but, i think we've got all the hiccups
figured out here, and i'm actually getting that 'warm fuzzy feeling'
about our project, and so is the end customer after seeing it run
today. On Friday, i was pretty sure this was gonna end up abandoned
due to reliablity issues. Re-writing the socket code was the answer,
and now, I think we actually will proceed to the end of our alpha
test cycle for sure, and probably be able to finish that cycle this
week. If we can get thru our test plan this week, and it goes all
week without a serious hiccup, then we'll proceed to beta cycle next
week, beta being the graduation from pretend account, to real money
account trading miniscule size.
