Sorry to hear that, looks like a bug. Please PM me the version you are running and we will attempt to reproduce. Thanks.
Some of the still existing pop-up cases: 1) Amex still prohibits electronic submission of options orders. Should your order go to Amex, a pop-up will show up. Should you desire, you can prevent it by: - not directing orders to Amex - excluding Amex from Smart 2) You can configure the distance from the NBBO, which will cause the orders the price of which violates the limit to pop up a message. Remedy: use wide threshold. In a future release we may direct this message to the API instead - a low priority item, so I would not expect it very soon. 3) If you request a market-data and don't have permissions. 4) If you are a Financial Advisor or Friends and Family account and you are issuing the order w/ invalid group or profile info.
I really appreciate your reply and honestly have to say that latest releases of TWS show several improvements over the past ones. Overall I could say I'm pretty satisfied with IB in general. That said, as you just admitted, there are still several popups left that show up in response to API events. None of the cases you cited above relate directly to me (fortunately). However, I'm strongly convinced the general principle here should be that if a user is connected through the API, *NO* message should be returned to him through popups: he should receive an API error code/message pair so that he could process it in a way appropriated to the application he's running. The best thing of course would be to have the choice of a bare API, without TWS, but if this is too far away in the future, then at least TWS should never interfere with API-based connections. If TWS keeps opening popups, the poor user has no way in principle to know in advance how many such cases there would be. If a user is connected through the API, it is safe to assume that what he wants to achieve is automation. Otherwise, he wouldn't need an API, isn't that right? But if TWS stops unpredictably, waiting for manual input, then full automation is simply not possible unless using some third party tool such as TWSStart. And even so, that's just a non official remedy based on undocumented TWS features. Yet this has been maybe the only way for IB API users to achieve automation, for a long time. Is that wrong? -GS
Thanks, dcraig. At least this case doesn't apply to me. The problem is that you cannot know in advance how many such cases there would be, and actually there shouldn't be any. See my previous post in this thread. -GS
Mr. NBBO: Further followup on the above points: 1 above) has been resolved. 3 above) we no longer route elsewhere and back. 4 above) is a major upgrade; we are roughly 50% there. IBsoft
Thanks again for resolving so many of the issues, especially the order lag. It's been a huge help already, my volume has definately picked up. Do the orders cancel & replace themselves on NY now, after 4-5min, or do the stay static on NY? To All ET'rs: I've been working with IB on really hunting down some bugs, they are VERY responsive, suprisingly so, even. If you have a genuine problem, they'll really do their best to get it fixed. Thanks again!
Thank you for the kind words and all the help you provided. Some of the issues were tricky to reproduce or hunt down. The details and specifics you provided made it possible to resolve them efficiently. (We cancel & replace in place).
There is a issue with the "regular hours only" option. When you put the "RTH" column on the sheet, even when the default RTH option is not choosen will always be checked as if it will only work during regular house. If you uncheck it and hit transmit again it gives a error message "modify mismatch onf field #6205". John
Likewise and agree they are (finally) doing their best to get these issues resolved. Would also ask that all ET'ers to forward details e.g time of incident and audit trails as they need details in order to trace, and thus fix these things.
Which version of TWS are you using? The "modify mismatch on field #6205" error message really means "IB does not support changing RTH-only flag on a submitted order". Thanks!