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.
OK. I never placed more more than one order within a millisecond. But
I can?t imagine that the use of a hi-resolution timer wouldn?t solve
all these id problems.
The GetTickCount function uses the PC Clock. So why don?t you use the
QueryPerformanceCounter? It uses the PC's clock counter but it reads
the current value of the countdown register in the timer chip to gain
more accuracy.
So you can go down to less than 1 microsecond (depending on your
machine speed you can even count the nanoseconds). To place an order
needs a least 5 to 10 microseconds - I guess. So you will never have
duplicate order id?s. At least I can?t believe that.
