开云体育

... I should add with the proposed code change, you can now stop the reader and disconnect the socket without actually destroying the EReader object by doing the following: ' The last line here is

What makes me feel uneasy is that according to the documentation: It makes users think that by calling eDisconnect() you can safely disconnect from TWS without causing errors but we have shown that

IDK if this is what made you uneasy or what you meant, but maybe you'd prefer to see the call to eDisconnect happen in readToQueue as the penultimate action (i.e. before the final signal is issued)?

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.