Hello.
I would like to extend the IB interface and would appreciate support from the forum.
To be able to give you a rough idea what experience I have in the programming context, and how the support can look like, here a short info.
Feel free to jump to point 3 (the goal) directly, the actual task.
Personal background
In the professional context I started as a software developer, but since a few years I am no longer active in the implementation context.
Nevertheless, in the conceptual framework and in application integration I still have a lot to do with developers/development.
However, I have remained privately faithful to programming.
A field in which I have been programming for more than 25 years deals with classical / modern AI, chess programming, engine programming.
Machine learning and optimization methods are interesting topics, which I still deal with regularly.
Mainly I program "C". C++/Java/C#/VB I can understand well.
Current state of knowledge
The challenge for me is to learn the new elements WL8, TWS, Framework WL8, TWS API, C# and trading itself in parallel, at the same time, for some weeks now. After the experiences of the last weeks I can orientate myself in all mentioned topics, but I always have gaps.
On the one hand, I lack contexts, on the other hand, there are simply gaps in knowledge and ultimately practical experience in the C# environment and the language characteristics.
Currently I could already implement the IB Api, develop and debug my first strategies from the VS IDE and that with C#, in the .Net environment. Like most of you too, besides family and job.
The Goal
Provide more order types from the IB environment. For example Bracket Orders, GTD, AON, IOC ...
Approach
I have now looked at some resources. It is not clear to me how lightweight the implementation can be.
The following terms allow different approaches and lead to different questions.
Broker Adapter, Broker Account, IBApi ...
My first idea was to extend with a class that simply implements the Order types via the IBApi.
However, I wonder how these orders would be placed from WL8 and especially how corresponding signals would be generated in WL8.
So, it is not clear to me how the interaction would be realized in this case with signals and the backtest.
If I implement the adapter, it is not clear to me with which effort this is related.
Currently I can't (yet) handle the rudimentary description.
As with my first idea, there are questions about the transaction management and the signals in WL.
Furthermore it is unclear to me whether the existing implementation can be used for the communication to the broker,
or the logic must also be overwritten and controlled.
With my level of knowledge I don't know how to approach the topic.
My intention
Finally I want to get deeper knowledge about the components and have fun with this project. After 25 years of engine programming, I am starting a new hobby.
If in the end a result comes out that provides new order types, that would be great.
My wish is that the experience of C# developers and also WL8 developers will speed up my learning curve considerably.
Any help is appreciated, whether it's a complete walk through, or help with a specific implementation. Now, how would you start?
I would like to extend the IB interface and would appreciate support from the forum.
To be able to give you a rough idea what experience I have in the programming context, and how the support can look like, here a short info.
Feel free to jump to point 3 (the goal) directly, the actual task.
Personal background
In the professional context I started as a software developer, but since a few years I am no longer active in the implementation context.
Nevertheless, in the conceptual framework and in application integration I still have a lot to do with developers/development.
However, I have remained privately faithful to programming.
A field in which I have been programming for more than 25 years deals with classical / modern AI, chess programming, engine programming.
Machine learning and optimization methods are interesting topics, which I still deal with regularly.
Mainly I program "C". C++/Java/C#/VB I can understand well.
Current state of knowledge
The challenge for me is to learn the new elements WL8, TWS, Framework WL8, TWS API, C# and trading itself in parallel, at the same time, for some weeks now. After the experiences of the last weeks I can orientate myself in all mentioned topics, but I always have gaps.
On the one hand, I lack contexts, on the other hand, there are simply gaps in knowledge and ultimately practical experience in the C# environment and the language characteristics.
Currently I could already implement the IB Api, develop and debug my first strategies from the VS IDE and that with C#, in the .Net environment. Like most of you too, besides family and job.
The Goal
Provide more order types from the IB environment. For example Bracket Orders, GTD, AON, IOC ...
Approach
I have now looked at some resources. It is not clear to me how lightweight the implementation can be.
The following terms allow different approaches and lead to different questions.
Broker Adapter, Broker Account, IBApi ...
My first idea was to extend with a class that simply implements the Order types via the IBApi.
However, I wonder how these orders would be placed from WL8 and especially how corresponding signals would be generated in WL8.
So, it is not clear to me how the interaction would be realized in this case with signals and the backtest.
If I implement the adapter, it is not clear to me with which effort this is related.
Currently I can't (yet) handle the rudimentary description.
As with my first idea, there are questions about the transaction management and the signals in WL.
Furthermore it is unclear to me whether the existing implementation can be used for the communication to the broker,
or the logic must also be overwritten and controlled.
With my level of knowledge I don't know how to approach the topic.
My intention
Finally I want to get deeper knowledge about the components and have fun with this project. After 25 years of engine programming, I am starting a new hobby.
If in the end a result comes out that provides new order types, that would be great.
My wish is that the experience of C# developers and also WL8 developers will speed up my learning curve considerably.
Any help is appreciated, whether it's a complete walk through, or help with a specific implementation. Now, how would you start?
Rename
Bracket orders (Limit/Stop exits) are already implemented with OCO binding. Let's start there.
It make little sense (to me) to implement the other order types for 99% of other users, but the APIs are documented and advanced users/programmers who have the resources can do what they will.
I don't see a way to "extend" the IB Broker Provider in this way. Providers must implement virtual methods with overrides. This is how Wealth-Lab communicates what's required. If you want different behaviors, you need to write your own provider.
As for getting order type information to the Broker Provider, short of us expanding the OrderType enumeration, you can use the Transaction.SignalName field to transmit other information you need to get to your broker provider.
It make little sense (to me) to implement the other order types for 99% of other users, but the APIs are documented and advanced users/programmers who have the resources can do what they will.
I don't see a way to "extend" the IB Broker Provider in this way. Providers must implement virtual methods with overrides. This is how Wealth-Lab communicates what's required. If you want different behaviors, you need to write your own provider.
As for getting order type information to the Broker Provider, short of us expanding the OrderType enumeration, you can use the Transaction.SignalName field to transmit other information you need to get to your broker provider.
Thanks Cone for your feedback.
No problem. I belong to the group that would like to try this out, but currently I lack the overview and as described the necessary experience in the given context. So, with a little help of the forum members i am still interested for various reasons.
Just to avoid a language issue. If you want to tell me that writing a Broker Adapter is not necessary, then i am happy to hear this. At least that is what i already thought/hoped. Of course i do not want to write my own API interface for IB. I want to learn to use the available ressources and to extend them for my needs and ideas. Therefor i need to know how things work and i need a content to start with. So the order types are my choice i can play with.
Indeed, a real provider extension does not seem necessary for this task.
Out of curiosity. What would a use case look like for you to implement the broker adapter? I mean you know the limits of WL very well.
So, this is the interesting part for the given task. Let's make an example. If we place an arder via WL8, how can i use the SignalName to make an AON order out of it?
Based on the documentation, I really would not have thought that this can be adapted to functional behavior. Or have I misunderstood you?
Perhaps we should also rename the topic, since it is not an extension of the broker interface. Ideas are welcome.
QUOTE:
It make little sense (to me) to implement the other order types for 99% of other users, but the APIs are documented and advanced users/programmers who have the resources can do what they will.
No problem. I belong to the group that would like to try this out, but currently I lack the overview and as described the necessary experience in the given context. So, with a little help of the forum members i am still interested for various reasons.
QUOTE:
I don't see a way to "extend" the IB Broker Provider in this way. Providers must implement virtual methods with overrides. This is how Wealth-Lab communicates what's required. If you want different behaviors, you need to write your own provider.
Just to avoid a language issue. If you want to tell me that writing a Broker Adapter is not necessary, then i am happy to hear this. At least that is what i already thought/hoped. Of course i do not want to write my own API interface for IB. I want to learn to use the available ressources and to extend them for my needs and ideas. Therefor i need to know how things work and i need a content to start with. So the order types are my choice i can play with.
Indeed, a real provider extension does not seem necessary for this task.
Out of curiosity. What would a use case look like for you to implement the broker adapter? I mean you know the limits of WL very well.
QUOTE:
As for getting order type information to the Broker Provider, short of us expanding the OrderType enumeration, you can use the Transaction.SignalName field to transmit other information you need to get to your broker provider.
So, this is the interesting part for the given task. Let's make an example. If we place an arder via WL8, how can i use the SignalName to make an AON order out of it?
Based on the documentation, I really would not have thought that this can be adapted to functional behavior. Or have I misunderstood you?
Perhaps we should also rename the topic, since it is not an extension of the broker interface. Ideas are welcome.
QUOTE:
Perhaps we should also rename the topic, since it is not an extension of the broker interface. Ideas are welcome.
Done.
Your Response
Post
Edit Post
Login is required