开云体育

Ok, maybe I wasn’t explicit enough. The point of step 7 is to demonstrate your original observation that after the first connection is broken, another client cannot get the data for that same

It is a good practice to retrieve contract objects from IBKR (rather than making them yourselves) as described in Requesting Contract Details (

may you try ISLAND instead of NASDAQ ?

Hello, I am trying to download historical data for a universe of US stocks and ETFs. I have code that creates a new contract and downloads the historical data. When I set the "contract.Exchange"

In other words... once all clients disconnect, you MUST re-connect with the same ID that the first connection was made with. It's a ridiculous requirement, I know... but that's the nature of this bug.

I previously thought that could be a solution too and so I actually tried using cancelMktData before disconnecting as well. I just tried it again and it doesn't solve the problem. However, it does

I agree that the old post is still relevant for reqMktData, Richard. I think I even said so. And price sampling at a rate of a few samples per second is also highly relevant and useful. But I cannot

I’ve managed to clarify exactly what the cause of this problem is, and it couldn’t be much simpler to describe. [It’s actually very easy to demonstrate the bug using IB’s own API sample

Oh, great! Thank you for showing interest and taking time to look into this. A second pair of eyes is always helpful and I definitely value your contribution. Merely confirming the same observation,

Jurgen Yes it is an old post, but it’s still accurate in its description of the basic mechanism. The sampling intervals are shorter now, especially for Forex, but it still works the same way.

No problems with the lengthy post, and thanks for the detail. I can confirm what you’re observing, after doing some quick and not-very-carefully controlled experiments earlier this evening.

... in addition to that, would I be able to buy at 4164,75? My guess is no. This is important to know, because in simulation you would normally take the ask price for market buy order. But if it

You're welcome. I'll add one "stupid trick" that has helped me when playing with initial design ideas. I'll first take a rough multi-processing approach and see how amenable the program is to being

Thank you! I need to spend some time thinking how to both acquire and analyze data simultaneous.

It sounds like you found your problem so I don't know exactly what you're trying to fix here. I can, however, offer advice w.r.t. writing multi-threaded code... avoid it like the plague! Lol, if you

It looks like I found culprit: thread locking. I pasted full code below. I implemented thread locking in order to make sure that list of tick data gets fully update before it is analyzed for any trade

First, sorry for the lengthy post. TLDR:? The sample code is a cut down, bare bones, test case meant to do nothing but tickle the inner-workings of TWS/IBGW 10.x in a way that highlights the core

Hello all, In trading the MES/ES futures, very often it happens that the highest bid is higher than than the lowest ask. This is usually no more than 0.25 or 0.50 points for a short period of time.

I think your claim is rather too strong. There may well be a bug as you suggest (I need to do my own test in another language to confirm it – I’m not equipped for Python), but it’s a very

Generally speaking I think the advice in this thread is pretty good. That said, it's actually possible that new versions of TWS/IBGW regress and introduce bugs that didn't exist before. Developers