Don't blame TWS for it. This is due to inadequate support for ActiveX on Excel. M$ has a long history of launching new hot mechanisms and not keep up work on them till they become 100%. It is funny that DDE at one time was touted as great. Then they kind of hid it onder the table pushing COM, COM+, DCOM, Activex etc. It seems that with Excel you have to go with good old DDE. I believe that Excel is OK for a quick demo with the TWS-API. If you want more it becomes quickly an inferior tool. Go to VB, C++, Delphi. The best is go to Linux with C++ or Kylix(=Delphi). nononsense
Is the TWS ActiveX object a type 1 (an ActiveX control) or a type 2 (a programmatically creatable COM object)?
It has been a tough battle to convince IB to fully open their API instead of launching TWS first, log on, then use your own software that consume the API. If it is authentication security related, what they've build into the TWS standalone, they can build into the API binary files distributed to everyone's desktop. The TWS not only make peopel feel inconvenient (keep both TWS and your own software running instead of one), but also cost extra overhead when transmitting data between IB's Internet data source to the front end with TWS sitting in the middle.
For the API call (reqAccountUpdates) that I have problem, I am not sure it's just the Excel. I got a few Events and Methods (like reqMktData, tickSize, tickPrice) working in Excel perfectly. Maybe the problem is in the call itself. There is even a error in IB's documentation: "reqAccountUpdates(boolean subscribe, strong acctCode)" It should be "string acctCode". And the problem is at the compiling stage ("wrong argument"). Does not look like an Excel VBA's problem to me. I think one may get the same compile error with VB 6.0 or VB.NET. I would appreciate if any one who is using VB.NET and IB ActiveX could try this reqAccountUpdates call and let me know what is the right argument. Thanks.
Hi All, Common sense seems to suggest a limit ought to exist on the number of active symbols in a trading type API. If not the servers would have to cope with a much heavier load which would be to the detriment of execution. All this is a matter of scale of course. If you require many symbols actively streaming and also insist on superior performance, you will probably have too look for a platform costing a lot more than IB's. nononsense
Hi All, Common sense seems to suggest a limit ought to exist on the number of active symbols in a trading type API. If not the servers would have to cope with a much heavier load which would be to the detriment of execution. All this is a matter of scale of course. If you require many symbols actively streaming and insist on superior performance, you will probably have too look for a platform costing a lot more than IB's. nononsense
I agree. I was hoping to use IB not so much from the cost standpoint but the fact that I've tried using Quote.com and eSignal and find them less reliable/accurate. My programs are also more prone to other glitches when using other feeds.