开云体育

My tool is extremely similar to yours, so no bottlenecks in code either.

I am doing this from my sim account. I should probably switch to my live account to hopefully get better times? <TwsApiOnGroupsIo@...> wrote:

Just after 15:10 US/Central this afternoon, I request Historical TickByTickLast data for Friday's NQZ3 session (20230928 17:00 through 20230929 16:00 US/Central): * I received 451,009 TickByTickLast

First of all, order status ApiPending is not an error condition. It is the state of your order(s) right after you placed them. And the Placing Orders (

I'm now having a seemingly identical problem using IB's python client -- I can only imagine I'm doing something boneheaded, but without documentation on the error, I'm a bit stuck. Running on v177, I

Running a script right now to get 2 years of tick data for NQ. Seems to be restricting my request limits to every 6 seconds. Are there times when this could improve? It is Sunday @ 2:30 p.m. where I

You may see this as a wart but I, personally, won't comment with regard to how intuitive things are or any design aesthetic. I _will_ say that consideration should be given to backward compatibility

I agree with everything you said although I am not entirely happy with my final solution. I do not feel that destroying the EReader object is the correct way to disconnect. It is certainly not

You're welcome. I think you've found an interesting oversight. Yeah, superficially and at first blush it would _seem_ that way. But it'd be a mistake to think so. I can understand how that initial

Thanks for your comment Buddy. I agree that the logic would seem that setting m_isAlive to false during the ~EReader() call should prevent the code trying to read from the socket. I tried playing

I guess the assumption is that using ```std::atomic<bool> m_isAlive;``` turns the following into a critical section: ``` void EReader::readToQueue() { //EMessage *msg = 0; while (m_isAlive) { if

After much deliberation, I think I figured out the problem. In my opinion it is a bug in the TWS API for C++. I would like someone's help to go thru' my logic and confirm it. The

I have faced a problem with my code for a long time that only occurs during the call to EClientSocket::eDisconnect() I have a separate message processing thread running which looks like this: I

Do you wait for the "Submit" status before submitting your next order? Can you submit orders without waiting for the status update? How do you measure time? I placed 8 orders (3 bracket orders) for 8

Thank you for taking the time to step through the VBA code. If I'm understanding correctly, you're saying that the problem exists in the separate ddedll.dll library file, which is a black box /

Jürgen wrote: "TWS/IBGW actually memorizes the highest orderId for each clientId and each account. I did not know this either for the longest time, but I think it was JG who made a comment related to

I just posted about RT Vol and bad ticks.? The last 2 days have been bad but still usable with filtering out extreme values for price.

@Richard I know that you were not trying to suggest one should use the same numerical ids for different request types. I just wanted to add another reason why one should not do it. Looks like we

I request live data with generic ticks set to RT Trade Volume (#375) which returns a trade volume string in addition to the regular default tick data (bid, ask, size etc).? ?Lately I've been getting

I never got a first nextValidID? < 100. Got things like "117", why ? never look at the why, I don't know of any zombie process and it works, so ... Your absolutely right, rules are more relax, and I