You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Codes to pull data from TWS Interactive Broker - C#
- Thread starter lordoftrades
- Start date
ha, of course here we go again. The OP asked about a C# solution. C# runs on .Net and currently IB does not offer a .Net version. ActiveX works but it can hardly be considered a .Net/C# library. IBSharp is on the other hand such library. Any issue you have with that? See, you may not like my way of putting things but I provide at least facts not stories or half-assed stuff. ActiveX is to C# what is DDE to Excel. Both are not considered stable and for that precise reason Microsoft is phasing out (has already) ActiveX, no more development on ActiveX. Anything you disagree with?
Quote from Craig66:
Oh God, here we go again...
Quote from hftvol:
there is no custom application when working with IBSharp. Its a mature library, it works, and it provides strong typing and socket communication, exactly what the OP asked for.
I was referring to your/his own application as custom application that communicates with TWS instance using strings and sockets.
To do that you can use IB library, someone else library or write your own based on code examples IB gives you. That is how Ibcsharp library was created - it is based on Java code from IB written in C#. ActiveX is just another option to access TWS instance functionality using IB library and is offered by IB. There is nothing special about it.
ah? Who is working with string? I never claimed I work with string. IBSharp is not based on Java, who gave you that idea? If anything then it most closely resembles the C++ library. And nobody claimed anything special about ActiveX, I just voiced my concern to stay away from anything ActiveX. It is not a stable interface. What do we disagree here on? I am getting confused.
OP, I recommend you look at IBSharp as someone else pointed out, it most closely assists someone wanting to access IB through C#.
OP, I recommend you look at IBSharp as someone else pointed out, it most closely assists someone wanting to access IB through C#.
Quote from vicirek:
I was referring to your/his own application as custom application that communicates with TWS instance using strings and sockets.
To do that you can use IB library, someone else library or write your own based on code examples IB gives you. That is how Ibcsharp library was created - it is based on Java code from IB written in C#. ActiveX is just another option to access TWS instance functionality using IB library and is offered by IB. There is nothing special about it.
Thank you all for tremendously response to my question, it's really awesome! I think we got a lot of stuff to start programming strategy monitoring now.
Kind regards
Espen
Kind regards
Espen
Quote from hftvol:
ah? Who is working with string? I never claimed I work with string. IBSharp is not based on Java, who gave you that idea? If anything then it most closely resembles the C++ library. And nobody claimed anything special about ActiveX, I just voiced my concern to stay away from anything ActiveX. It is not a stable interface. What do we disagree here on? I am getting confused.
OP, I recommend you look at IBSharp as someone else pointed out, it most closely assists someone wanting to access IB through C#.
IB API is string passing protocol using sockets and all what the API does is to work on null delimited fields of strings passed between TWS which runs on your computer and your custom application running on the same or networked machine. The bottom line is that it boils down to strings regardless how they are translated in the process.
I cannot back it up but what I have read on Dinosaurtech webpage some time ago it was saying it is ported IB Java code to C# with changes and improvements (TWS is Java based). It could be C++ as well which would make little difference since you have to use IB protocol to read and create strings that go back and forth between 2 applications and both Java and C++ would map to the same protocol over sockets.
ActiveX and COM are still widely used (lots of legacy code) and not going away anytime soon. It is being replaced by newer technology based on the same concept of separating interface and providing implementation in binary form in standardized package with added benefit of taking care of threading, memory, object creation and finalization etc.. Stability is not the main issue with ActiveX but rather versioning, deployment, code maintenance and bad rap due to security issues. In case of IB it is the fastest way of creating testing environment by incorporating it to .Net application.
IBCsharp is professional grade third party library and is highly recommended as a solution for IB connectivity using .Net and there is no doubt about it. I have heard that there are many happy users not mentioning professional shops implementing it.
I doubt that any professional grade application would be based on ActiveX. They are mostly using sockets directly with C++ or Java.
Re string, not everything in the C++ API is string based, though a lot is. Here is the link to their API, you can check out the socket functions for both, C++ and Java. I do not see a problem with that, though.
http://www.interactivebrokers.com/en/software/api/api.htm
I still think the fastest way, given one targets C#, is to simply plug in IBCSharp (its even available on Nuget, could not be simpler). A lot of the connectivity stuff is taken care of, something you would have to handle yourself if you used ActiveX.
But I agree, ActiveX is also very simple to get started.
http://www.interactivebrokers.com/en/software/api/api.htm
I still think the fastest way, given one targets C#, is to simply plug in IBCSharp (its even available on Nuget, could not be simpler). A lot of the connectivity stuff is taken care of, something you would have to handle yourself if you used ActiveX.
But I agree, ActiveX is also very simple to get started.
Quote from vicirek:
IB API is string passing protocol using sockets and all what the API does is to work on null delimited fields of strings passed between TWS which runs on your computer and your custom application running on the same or networked machine. The bottom line is that it boils down to strings regardless how they are translated in the process.
I cannot back it up but what I have read on Dinosaurtech webpage some time ago it was saying it is ported IB Java code to C# with changes and improvements (TWS is Java based). It could be C++ as well which would make little difference since you have to use IB protocol to read and create strings that go back and forth between 2 applications and both Java and C++ would map to the same protocol over sockets.
ActiveX and COM are still widely used (lots of legacy code) and not going away anytime soon. It is being replaced by newer technology based on the same concept of separating interface and providing implementation in binary form in standardized package with added benefit of taking care of threading, memory, object creation and finalization etc.. Stability is not the main issue with ActiveX but rather versioning, deployment, code maintenance and bad rap due to security issues. In case of IB it is the fastest way of creating testing environment by incorporating it to .Net application.
IBCsharp is professional grade third party library and is highly recommended as a solution for IB connectivity using .Net and there is no doubt about it. I have heard that there are many happy users not mentioning professional shops implementing it.
I doubt that any professional grade application would be based on ActiveX. They are mostly using sockets directly with C++ or Java.
Quote from hftvol:
Re string, not everything in the C++ API is string based,
I guess I went one unnecessary technical detail to far for IB API. Even if the method shows for example that you read double it was internally converted from char array to double and vice versa. The iterface is showing variety of data types but message passing internally is based on strings. Anyway for string passing protocol this API is over-engineered.
Out of curiosity, care to show me an example of IB code that is purely based on string passing? I guess with "internally" you mean the core IB API? I have not seen what you suggest so would be curious. Not that I spent too much time on it, I do not execute much aside FX through IB and even that goes through FIX.
But I am interested in what you said about the string passing aspect of the IB API.
THanks
But I am interested in what you said about the string passing aspect of the IB API.
THanks
Quote from vicirek:
I guess I went one unnecessary technical detail to far for IB API. Even if the method shows for example that you read double it was internally converted from char array to double and vice versa. The iterface is showing variety of data types but message passing internally is based on strings. Anyway for string passing protocol this API is over-engineered.