开云体育

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

thank you for the clarification. Gives me a better handle on what's going on. I'm going to rationalize my data approach in 2024 as I have MANY experimental scripts ( python, julia, and now mojo) which

Good luck with log reading. I hope it helps you find the root cause. I removed lots of log detail in the hope that would make things clearer, but apparently it did not. To summarize the log one more

thank you AGAIN for such a detailed analysis.? I have turned on the HMDS logging feature for extra detail, thanks again for the heads up.? I am always a little nervous when there is a hint of data

You are welcome. Generally, IBKR has relaxed historical data pacing rules over the years, but in the spirit of "did something change", here a couple of observations. This is "thin ice territory" in

Jürgen I wasn’t trying to suggest that one should use the same order ids for different request types, merely that the rules are far more relaxed than Gordon’s post implied. Indeed, what

WOW that's my bad sorry. the last date the program worked was Thu 21 Sep *2023* 02:11:09 AM then the next day Fri 22 Sep 2023 02:11:09 AM CDT? it failed to get any data.? Excellent work Holmes