API's

Quote from TGregg:


Hi,

I know you mentioned that this was from Excel, and not from VB.Net, but it's kinda strange that VB->ActiveX->TWS works perfectly, but Excel->ActiveX->TWS does not, and is apparently sigificant work (by IB) to support. One would expect that if these were not identical, then they would be nearly so.
More...

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
 
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.
 
Quote from TGregg:



I know you mentioned that this was from Excel, and not from VB.Net, but it's kinda strange that VB->ActiveX->TWS works perfectly, but Excel->ActiveX->TWS does not, and is apparently sigificant work (by IB) to support. One would expect that if these were not identical, then they would be nearly so.
More...

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.
 
Has anybody else requested this data limitation be increased as well? Perhaps for a minimal fee?


Quote from H2O:

Let's first start with a complaint....

I really like the IB API, but as far as I know, there's a SYMBOL limit of 40 symbols. And this includes the symbols you're viewing in your TWS.

I think this really is a problem when working with the API.
I would like to use their API for the purpose of handling multiple positions at once (More than I can handle manually)

Now they announce a 40 symbol limit, including the TWS screen.

IB please get this up to 100 or so....:)
More...
 
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.

Quote from 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
More...
 
You must log in or register to reply here.
Back
Top