IMO - is more than the API's ease of use, reliability, and speed (although each of these are important)...it's also features like; smart order routing, automatic trailing stops, fast change/modify order operations, and advanced price improvement "features" on both entry and exit. I'm still looking...
I have a question about api programming specifically capturing events. I have a VB program that captures an order ID everytime I send an ActiveX order object to my system. It is stored in memory. It generally works ok but sometimes it only captures 98% of the order ID's This means that I have live orders in my platform that my API does not see. Can anyone offer a reason why this could happen? Ex. I would submit 15 orders and I would see all 15 OrderId's in my API in VB. I cancel them and re-submit 15 new ones, sometimes only 13 OrderID's would show up in my auto system so if I need to cancel all opens, only 13 of the 15 would be cancelled since it does not see the 2? I don't think it is a faulty internet connection since the main platform sees the 15 orders. Do you think I should put a pause command in VB to give the system time to catch up after every order submit Thanks in advance.
That's a tricky problem...are you using VB6 or VB7? When you say the order server sees the 15 new orders, is it correct to assume the client (API) assigns the order ID's and invokes an event when the order is submitted, or does it submit the order and generate the event when it received a reply (confirmation of the order) from the server? If it's the latter, you could use a network sniffer to verify that all of the responses are arriving back from the server as expected. In other cases, or perhaps in all cases, there are "issues" with COM eventing and method calls, due to the nature of its single-threading model used with VB (e.g. methods and events are delivered via the thread's "Windows Message Que" and sometimes those calls can dissapear or not appear as/when expected. I recommend using VB7 as it has better threading support, and maybe an Ack/AckTimeout retry mechanism for delivering messages between the lowest level of the API and your client application...if you have control over the API source...if not, then you may have to try and implement some kind of timeout mechanism in the client application, then when it occurs, poll the API and fetch the open-orders list to re-sync with the event driven client. Just some ideas...if you have more info maybe I can come up with other/better suggestions.
I've have seen IB folks in several fora say that the Sockets API is preferred because Microsoft has told them that ActiveX events are not 100% reliable. If that's true the API probably needs to include some additional error/loss checking.