Maybe in this case the multimedia timer or a high-resolution timer
could help you.
The real answer is to understand how to get id's allocated from tws.
Everybody is under the mistaken impression, the NextId callback is
the one to use, it's not. You use the request ids call, to reserve a
block, then the nextid will make a jump from what it was, to the next
one after your block. Now those id's are allocated, and safe to use,
the only issue, is dealing with the problem of multiple allocations
occuring at the same time. By going this route, there should be no
chance of hitting duplicates, and if you start getting duplicate id
messages, it's because you are modifying orders before they are
actually 'in and working'. You cannot modify an order between the
time you call placeorder, and you get the callback saying it has been
placed. If you are doing trailing stops, it's easy to 'accidently'
modify a stop during this timeframe, if you dont watch out for the
specific circumstance.
My applicaton allocates a block of 1000 id's when it starts, and due
to the potential time lag from requesting more, to actually getting
them, I request a new block when I've used up 800 of the 1000.
Tonite i've been fiddling with issues during partial fill sequences,
I finally figured out a way to reliably get partials from the demo.
Load up a buy order for 15 nq, then sit and wait for the offer to
show size of 8 or less. Lift that offer with a limit order. If the
offer is 1, you'll get a string of 15 individual fills, scattered
over approximately 2 seconds. If you have logic to throw in stops
and targets on fills, it's an ideal way to test it, because you'll
have the initial order in on the first fill, then you have every
possible bad timing issue repeat for the rest of them, and your code
to update the stops and targets will not go off on every fill,
because you'll have orders in the 'pending callback' state.
I actually added a bit of code onto the tickprice handler, to 'lie in
wait' for the correct time, then let loose the orders to buy/short
with as many as the demo will allow. This is an exercise well worth
doing, because if your code has any accidental timing dependancies in
it, you will find them with this exercise. Once i figured out the
way to reliably get partials, what I thought was going to be a simple
verify that some handlers were working correctly, turned into anohter
session of 'wtf is this thing doing now ??'
Options are going to be even more interesting, because we'll have to
observe the 1 second limitations. To prevent automated trading, the
exchanges mandate the brokers dont accept orders at a rate of higher
then one per second on any given customer account for options. Gonna
be interesting figuring out just how accurate the timers for this are
at ib, and just how much time we will really have to introduce
between options orders. I suspect to be safe, it's going to have to
be on the order of 1.2 seconds or longer. If your application is
going to be doing groups of options orders, it'll need to set up an
order que, and then peel orders off the que at the maximum allowd
rate, to forward them for handling.
