Re: how to pause execution
One issue to keep in mind when cancelling orders as opposed to manually "unsubmitting" them in TWS is how that could count toward IBKR order cancellation guidelines as I believe there?are fees for non-SMART order cancellation via API above a certain balance against executions ().
|
Re: Choose between: Client Portal API & TWS API
You are welcome, Yu.
The basic objects and concepts are the same between TWS API and the Web Portal API, so if in doubt, look at the TWS API documentation. Generally, you would make contract database lookups to retrieve contract IDs (conIds)? for more "human readable" descriptions of the instrument(s) you are interested in. Take a look atI and .
Internally, TWS and IBGW are pretty much identical. We have not done it for the very latest versions, but when we compared that jars and classes for the same TWS and IBGW versions last year, they were virtually identical.
IBGW will most likely use a little less memory, probably has fewer threads, and may use a little less CPU. IIBGW does not have to manage a complex UI with many moving and graphics intensive parts so there are fewer things that can go wrong. You also will have fewer pop-ups and "helpful" hints.
If you know you won't use the GUI, go with IBGW. Your clients will not see a difference other than the four different default ports {IBGW, TWS} x {Paper, Live}.
Which implementation language are you thinking of?
´³¨¹°ù²µ±ð²Ô
toggle quoted message
Show quoted text
On Fri, Feb 4, 2022 at 12:05 PM, PurpleIce wrote:
A couple follow-ups:
- TWS vs IBGW: any pros & cons? I only know that IBGW is more lightweight.
- Can my client software run on a different machine than the TWS/IBGW (which means using Internet to connect the two)?
|
Re: how to pause execution
For the sake of perfectionism, I did another quick test and it looks like modifying an existing submitted order with ::Transmit = false does nothing. Which could reasonably, though not strictly, be expected from how the API documentation approaches the problem of order modification (it "generally" recommends changing only size, price and tif).
|
Re: Choose between: Client Portal API & TWS API
Hi Jurgen,
Thank you for such insightful comments on the two APIs.
I tried Web Portal API a bit but found very little help available on Internet for even simple questions, e.g. RequestMarketData uses ContractID to represent stocks but there is no such a mapping.
I joined this group hoping to get helps; now it seems TWS API is the correct one to go.
A couple follow-ups:
- TWS vs IBGW: any pros & cons? I only know that IBGW is more lightweight.
- Can my client software run on a different machine than the TWS/IBGW (which means using Internet to connect the two)?
A bit context about me:
I'm a software?engineer with 12 years experience, worked on many projects including deep learning. I have expertise in speech recognition and voice matching. I recently developed a system that showed promising back-tests, so I'd like to test for real. Hope
I can contribute to this email group sometime soon!
toggle quoted message
Show quoted text
We started a few years back with the TWS API before the Web Portal API was available. We found the TWS API full featured for what we are doing, stable, and with very reasonable latencies (remember, you are talking to a brokerage). We run our clients and
TWS instances in virtual Linux instances that is located close to the US east coast IBKR systems (from an IP round-trip latency point of view).
People that come from a traditional blocking request/response API mentality have to get their head around the asynchronous nature of the TWS API. But once you do, it fits very nicely into modern reactive/asynchronous/stream based application frameworks and
architectures.
The API implementations IBKR provides for various languages (and that we are discussing here) are very low level. They pretty much provide only serializers/deserializers for the individual API methods at the socket level. While some people feel that is insufficient,
we felt (and still feel) that this gives us the freedom to integrate the API in the most effective way for our application architectures. TWS API does not force you to follow a specific application architecture.
But you will want use an abstraction layer to hide the API details from your application and business logic. For example, hide the concept of requestId from your application (they relate API responses to your requests or subscriptions) and never try to synchronize
responses with requests by constant or variable length "sleep". Take a look at the ApiController class in the Java API source for a great example of how to do that. It is pretty much a complete MVC "controller" implementation for communicating with the API.
We do find it very beneficial to have TWS running so that we have immediate manual access to the accounts our API clients are managing. There are weeks when we do not touch the GUI but you have the ability for manual interventions as soon as something does
not sound right.
We did evaluate the Web Portal API about a year ago, but feel, it is not ready for use yet (at least for us). Here are the highlights:
- The latest and stable versions of the API are two years old, but the portal as well as TWS/IBGW and TWS API have added many features since. The largest of them was support for Crypto instruments late last year.
- From the outside it feels like IBKR's focus is on TWS/IBGW and TWS API. That is understandable since that is where the main user base is. For the foreseeable future, TWS API will most likely be more stable and more frequently be improved than Web Portal
API.
- Web Portal API has the same simultaneous account login and market data sharing limitations that TWS/IBGW have and it does not provide any additional features we need.
- Web Portal API comes with a small gateway and your REST requests are actually made locally, not directly to IBKR. Granted, that gateway is much smaller and leaner than TWS/IBGW, but your operation still needs to assure stability and health of the gateway
just like you would with TWS/IBGW.
- While we found the methods reasonably well designed and the like you would expect from a modern REST API, Client Portal API will not be able to give you the "loosely coupled" and distributed architecture you might expect from a REST API due to the need of the local gateway
We definitely would love to learn from your experience should you decide to work with Web Client Portal API. And who knows, some of our members may be able to answer questions, too.
´³¨¹°ù²µ±ð²Ô
On Fri, Feb 4, 2022 at 04:40 AM, PurpleIce wrote:
?
I see most people are using TWS API; I wonder why they don't use Client Portal API? Anyone shares a comparison?
?
?
|
Re: Choose between: Client Portal API & TWS API
We started a few years back with the TWS API before the Web Portal API was available. We found the TWS API full featured for what we are doing, stable, and with very reasonable latencies (remember, you are talking to a brokerage). We run our clients and TWS instances in virtual Linux instances that is located close to the US east coast IBKR systems (from an IP round-trip latency point of view).
People that come from a traditional blocking request/response API mentality have to get their head around the asynchronous nature of the TWS API. But once you do, it fits very nicely into modern reactive/asynchronous/stream based application frameworks and architectures.
The API implementations IBKR provides for various languages (and that we are discussing here) are very low level. They pretty much provide only serializers/deserializers for the individual API methods at the socket level. While some people feel that is insufficient, we felt (and still feel) that this gives us the freedom to integrate the API in the most effective way for our application architectures. TWS API does not force you to follow a specific application architecture. But you will want use an abstraction layer to hide the API details from your application and business logic. For example, hide the concept of requestId from your application (they relate API responses to your requests or subscriptions) and never try to synchronize responses with requests by constant or variable length "sleep". Take a look at the ApiController class in the Java API source for a great example of how to do that. It is pretty much a complete MVC "controller" implementation for communicating with the API. We do find it very beneficial to have TWS running so that we have immediate manual access to the accounts our API clients are managing. There are weeks when we do not touch the GUI but you have the ability for manual interventions as soon as something does not sound right. We did evaluate the Web Portal API about a year ago, but feel, it is not ready for use yet (at least for us). Here are the highlights:
- The latest and stable versions of the API are two years old, but the portal as well as TWS/IBGW and TWS API have added many features since. The largest of them was support for Crypto instruments late last year.
- From the outside it feels like IBKR's focus is on TWS/IBGW and TWS API. That is understandable since that is where the main user base is. For the foreseeable future, TWS API will most likely be more stable and more frequently be improved than Web Portal API.
- Web Portal API has the same simultaneous account login and market data sharing limitations that TWS/IBGW have and it does not provide any additional features we need.
- Web Portal API comes with a small gateway and your REST requests are actually made locally, not directly to IBKR. Granted, that gateway is much smaller and leaner than TWS/IBGW, but your operation still needs to assure stability and health of the gateway just like you would with TWS/IBGW.
- While we found the methods reasonably well designed and the like you would expect from a modern REST API, Client Portal API will not be able to give you the "loosely coupled" and distributed architecture you might expect from a REST API due to the need of the local gateway
We definitely would love to learn from your experience should you decide to work with Web Client Portal API. And who knows, some of our members may be able to answer questions, too. ´³¨¹°ù²µ±ð²Ô
On Fri, Feb 4, 2022 at 04:40 AM, PurpleIce wrote:
?
I see most people are using TWS API; I wonder why they don't use Client Portal API? Anyone shares a comparison?
?
?
|
Re: Choose between: Client Portal API & TWS API
On Fri, Feb 4, 2022 at 03:40 AM, PurpleIce wrote:
I'm a software engineer and new to IB API. I'm exploring auto trading strategies.
I see most people are using TWS API; I wonder why they don't use Client Portal API? Anyone shares a comparison?
?
?I think most people here are not familiar with the Client Portal API. I have been working with the TWS API since 2002, and I had not heard of the Client Portal API before you mentioned it. [rwk]
|
Re: how to pause execution
|
Re: Conditions on twsactivex api
Joan ? I'll try to find some time for this soon, but it won't be today, so it'll be next week before I can actually try placing orders. ? Just one thing: the information you quoted from your API log is missing the important stuff: I'm not interested in the error message, I'm interested in the message from the API to TWS that contains the order details, and which caused the error message. This should be just before the error message, so shortly before 18:32:06:634: in fact it will probably be the previous line in the logfile. It'll be a really long message that will include the encoded condition along with all the other stuff for the order. I want to be able to see exactly what bytes were generated for this order. So please can you quote that line. ? Richard ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of joanmarcel119
Sent: 03 February 2022 17:49
To: [email protected]
Subject: Re: [TWS API] Conditions on twsactivex api? Wow Richard, that is very kind of you, if you could please debug it, that?would be great, thank you very much! I tried but I'm having some issues preparing the C# program to debug, a lot of lost references, classes... I need to refresh how everything works together and I also have xml compatibility?issues with the Microsoft Visual Studio 15. to set the?previous order use the following: Type | Last trade date | Strike | P/C | Multiplier | Exchange | Prim Exch | Currency | Local Symbol | Con Id | Combo Legs | Delta-Neutral | Action | Quantity | Cash Qty | Order Type | Lmt Price |
FUT | ? | ? | ? | ? | NYBOT | ? | USD | CTK2 | ? | ? | ? | BUY | 1 | ? | LMT | 1.13 |
Then on DN column on the same tab: 1) you can try first with the demo example that works, placing: last of bid/ask Price of 8314(SMART) is <= 0? ? ? It should run as expected and create a conditional order on the IBM stock 2) then try please the following: last Price of 269459887(GLOBEX) is >= 1.15? you will get the following error on API log: 18:31:51:424 -> ---:4-2--1-2104-Market data farm connection is OK:usfuture.nj-
18:31:51:424 -> ---44-2--1-2104-Market data farm connection is OK:hfarm-
18:31:51:424 -> ---84-2--1-2104-Market data farm connection is OK:usfarm.nj-
18:31:51:424 -> ---54-2--1-2104-Market data farm connection is OK:eufarm-
18:31:51:424 -> ---74-2--1-2104-Market data farm connection is OK:usfuture-
18:31:51:424 -> ---74-2--1-2104-Market data farm connection is OK:cashfarm-
18:31:51:424 -> ---54-2--1-2104-Market data farm connection is OK:usfarm-
18:31:51:424 -> ---34-2--1-2106-HMDS data farm connection is OK:ushmds-
18:31:51:424 -> ---84-2--1-2158-Sec-def data farm connection is OK:secdefil-
18:32:06:634 -> --- 4-2-1879051859-320-Error reading request.Message id 1879051859.? Unable to parse data. java.lang.NumberFormatException: For input string: "GLOBEX"-
18:32:06:634 <- 2-0-0-
18:32:06:634 -> ---)4-2-0-300-Can't find EId with tickerId:0- 2022-02-03 18:35:28.874 [EF] INFO ?[JTS-EServerSocket-1608] - [0:157:157:1:0:0:0:ERR] Message id 1879051859.? Unable to parse data. java.lang.NumberFormatException: For input string: "GLOBEX"
2022-02-03 18:35:28.878 [EF] INFO ?[JTS-EServerSocket-1608] - [0:157:157:1:0:0:0:ERR] Invalid incoming request type - 0
2022-02-03 18:35:28.878 [EF] ERROR [JTS-EServerSocket-1608] - [0:157:157:1:0:0:0:ERR] Client socket broken -
java.lang.NumberFormatException: For input string: "1.79769313486232E+308"
at java.lang.NumberFormatException.forInputString(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at jextend.bh.p(bh.java:921)
at jextend.dV.a6(dV.java:2615)
at jextend.dV.run(dV.java:2202)
at java.lang.Thread.run(Unknown Source) Thank you very much again ? El jue, 3 feb 2022 a las 0:47, Richard L King (<rlking@...>) escribi¨®: It's not really possible to debug the TWSLib when it's invoked from Excel. But It would be pretty straightforward to write a small C# program that calls the TWSLib API functions, with a suitable simple condition string, and step through that in the debugger (note that the VBA in the Excel workbook doesn't really do anything except call the TWSLib methods, so there's no need to have Excel involved at all). ? You could then have a variant of this program that calls the C# API functions directly for the same condition: if these two programs differ in their interaction with TWS, that would give a good clue as to where the problem lies. ? As it happens, I have a sample API demo program that exists in two versions: one uses the ActiveX TWSLib, and the other uses the C# API, so I could do what I suggested above with relatively little effort. If you like, I'll try to find time for this, but if you¡¯ve got another way to progress this, I'd rather not spend the time on it. ? By the way, it would be helpful if you could give us an extract from the API log that includes the place order message from the API to TWS, rather than just the response from TWS, so we can see exactly what's being sent. ? ? Hi ´³¨¹°ù²µ±ð²Ô, thank you again, however regarding the twsactivex?api the data input is all coming from the excel cells and transformed accordingly by the demo program. This issue that I currently have its happening on the demo Excel provided by IB and I did check the function and it gets the conditions well parsed, the issue comes after sending the order? to the TWS?using the Api.Tws.placeOrderEx function? anyone in this group, please, do you know if it is possible to debug the placeOrderEx function? Or is it better to contact IB and report the potential bug on their API? ?
|
Choose between: Client Portal API & TWS API
Dear group,
I'm a software engineer and new to IB API. I'm exploring auto trading strategies.
I see most people are using TWS API; I wonder why they don't use Client Portal API? Anyone shares a comparison?
Thank you!
|
Re: IB's WebAPI - partial fill in paper account with no orderId returned
Not sure which version of the "Client Portal API" you are using, Michael. The latest and beta versions available through the page seem to be from August 2020 with many files time stamped much older than that. Crypto was added in 10dot versions of TWS and TWS API late 2021 and the Client Portal API might just have incomplete Crypto support. Would probably be a question for IBKR API support.
Do you get the results you are looking for if you make your requests with a STK/ETF/FUT/... instrument?
´³¨¹°ù²µ±ð²Ô
|
Re: IB's WebAPI - partial fill in paper account with no orderId returned
Some exchanges prohibit automatic trading of some instruments. I don't know about crypto currencies specifically, you might want to contact IB.
toggle quoted message
Show quoted text
On 2/3/2022 3:01 PM, Michael Sutton wrote: However, I'm unable to disable a transmit confirm message box for all crypto orders.
|
Re: IB's WebAPI - partial fill in paper account with no orderId returned
It appears I can get around this limitation with TWS by disabling that qty check in TWS's settings.
However, I'm unable to disable a transmit confirm message box for all crypto orders.? This seems totally crazy.? What am I missing??!!
It defeats anything I could do with the API and crypto!? There must be some type of workaround.
|
Re: Conditions on twsactivex api
Wow Richard, that is very kind of you, if you could please debug it, that?would be great, thank you very much!
I tried but I'm having some issues preparing the C# program to debug, a lot of lost references, classes... I need to refresh how everything works together and I also have xml compatibility?issues with the Microsoft Visual Studio 15. ? to set the?previous order use the following:
| Type |
Last trade date |
Strike |
P/C |
Multiplier |
Exchange |
Prim Exch |
Currency |
Local Symbol |
Con Id |
Combo Legs |
Delta-Neutral |
Action |
Quantity |
Cash Qty |
Order Type |
Lmt Price |
| FUT |
? |
? |
? |
? |
NYBOT |
? |
USD |
CTK2 |
? |
? |
? |
BUY |
1 |
? |
LMT |
1.13 |
Then on DN column on the same tab: 1) you can try first with the demo example that works, placing: last of bid/ask Price of 8314(SMART) is <= 0? ? ? It should run as expected and create a conditional order on the IBM stock 2) then try please the following: last Price of 269459887(GLOBEX) is >= 1.15?
you will get the following error on API log: 18:31:51:424 -> ---:4-2--1-2104-Market data farm connection is OK:usfuture.nj-
18:31:51:424 -> ---44-2--1-2104-Market data farm connection is OK:hfarm-
18:31:51:424 -> ---84-2--1-2104-Market data farm connection is OK:usfarm.nj-
18:31:51:424 -> ---54-2--1-2104-Market data farm connection is OK:eufarm-
18:31:51:424 -> ---74-2--1-2104-Market data farm connection is OK:usfuture-
18:31:51:424 -> ---74-2--1-2104-Market data farm connection is OK:cashfarm-
18:31:51:424 -> ---54-2--1-2104-Market data farm connection is OK:usfarm-
18:31:51:424 -> ---34-2--1-2106-HMDS data farm connection is OK:ushmds-
18:31:51:424 -> ---84-2--1-2158-Sec-def data farm connection is OK:secdefil-
18:32:06:634 -> --- 4-2-1879051859-320-Error reading request.Message id 1879051859.? Unable to parse data. java.lang.NumberFormatException: For input string: "GLOBEX"-
18:32:06:634 <- 2-0-0-
18:32:06:634 -> ---)4-2-0-300-Can't find EId with tickerId:0-
on TWS log: 2022-02-03 18:35:28.874 [EF] INFO ?[JTS-EServerSocket-1608] - [0:157:157:1:0:0:0:ERR] Message id 1879051859.? Unable to parse data. java.lang.NumberFormatException: For input string: "GLOBEX"
2022-02-03 18:35:28.878 [EF] INFO ?[JTS-EServerSocket-1608] - [0:157:157:1:0:0:0:ERR] Invalid incoming request type - 0
2022-02-03 18:35:28.878 [EF] ERROR [JTS-EServerSocket-1608] - [0:157:157:1:0:0:0:ERR] Client socket broken -
java.lang.NumberFormatException: For input string: "1.79769313486232E+308"
at java.lang.NumberFormatException.forInputString(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at jextend.bh.p(bh.java:921)
at jextend.dV.a6(dV.java:2615)
at jextend.dV.run(dV.java:2202)
at java.lang.Thread.run(Unknown Source)
Thank you very much again
El jue, 3 feb 2022 a las 0:47, Richard L King (< rlking@...>) escribi¨®: It's not really possible to debug the TWSLib when it's invoked from Excel. But It would be pretty straightforward to write a small C# program that calls the TWSLib API functions, with a suitable simple condition string, and step through that in the debugger (note that the VBA in the Excel workbook doesn't really do anything except call the TWSLib methods, so there's no need to have Excel involved at all). ? You could then have a variant of this program that calls the C# API functions directly for the same condition: if these two programs differ in their interaction with TWS, that would give a good clue as to where the problem lies. ? As it happens, I have a sample API demo program that exists in two versions: one uses the ActiveX TWSLib, and the other uses the C# API, so I could do what I suggested above with relatively little effort. If you like, I'll try to find time for this, but if you¡¯ve got another way to progress this, I'd rather not spend the time on it. ? By the way, it would be helpful if you could give us an extract from the API log that includes the place order message from the API to TWS, rather than just the response from TWS, so we can see exactly what's being sent. ? ? Hi ´³¨¹°ù²µ±ð²Ô, thank you again, however regarding the twsactivex?api the data input is all coming from the excel cells and transformed accordingly by the demo program. This issue that I currently have its happening on the demo Excel provided by IB and I did check the function and it gets the conditions well parsed, the issue comes after sending the order? to the TWS?using the Api.Tws.placeOrderEx function? anyone in this group, please, do you know if it is possible to debug the placeOrderEx function? Or is it better to contact IB and report the potential bug on their API? ?
|
Re: reqHistoricalData() for OTC only works if first typed symbol in TWS
So it seems that the fix I described above does not persist.? If I first pull up a chart in TWS then I can download data (e.g. SIEGY (PINK.CURRENT)).? Otherwise, I get "error: tid: 5006, errorCode: 162, msg: Historical Market Data Service error message:No market data permissions for ARCAEDGE STK".
|
IB's WebAPI - partial fill in paper account with no orderId returned
Is there a better place to post a question for IB's WebAPI/REST?? If so, please let me know.? I haven't found a dedicated group.
In a paper account, I'm trying to submit a market order for BTC.? Apparently, the order partially fills (probably a paper account artifact??), but I have no way to determine how much filled because only the error is returned and no order id to use for subsequent order status queries.
I'm submitting to the?/v1/api/iserver/account/{account_id}/orders endpoint with these parameters:
{'orders': [{'conid': 479624278, 'side': 'BUY', 'orderType': 'MKT', 'tif': 'IOC', 'listingExchange': 'PAXOS', 'cashQty': 37500.0}]}
I receive the following error back.?
{'error': 'The market order was partially executed. Remaining quantity of 1.26749644 was removed.', 'suggestedSize': 1.27756125, 'suggestedCashSize': 46874.99982375}
|
Re: Conditions on twsactivex api
It's not really possible to debug the TWSLib when it's invoked from Excel. But It would be pretty straightforward to write a small C# program that calls the TWSLib API functions, with a suitable simple condition string, and step through that in the debugger (note that the VBA in the Excel workbook doesn't really do anything except call the TWSLib methods, so there's no need to have Excel involved at all). ? You could then have a variant of this program that calls the C# API functions directly for the same condition: if these two programs differ in their interaction with TWS, that would give a good clue as to where the problem lies. ? As it happens, I have a sample API demo program that exists in two versions: one uses the ActiveX TWSLib, and the other uses the C# API, so I could do what I suggested above with relatively little effort. If you like, I'll try to find time for this, but if you¡¯ve got another way to progress this, I'd rather not spend the time on it. ? By the way, it would be helpful if you could give us an extract from the API log that includes the place order message from the API to TWS, rather than just the response from TWS, so we can see exactly what's being sent. ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of joanmarcel119
Sent: 02 February 2022 20:31
To: [email protected]
Subject: Re: [TWS API] Conditions on twsactivex api? Hi ´³¨¹°ù²µ±ð²Ô, thank you again, however regarding the twsactivex?api the data input is all coming from the excel cells and transformed accordingly by the demo program. This issue that I currently have its happening on the demo Excel provided by IB and I did check the function and it gets the conditions well parsed, the issue comes after sending the order? to the TWS?using the Api.Tws.placeOrderEx function? anyone in this group, please, do you know if it is possible to debug the placeOrderEx function? Or is it better to contact IB and report the potential bug on their API? ?
|
Re: Conditions on twsactivex api
Hi ´³¨¹°ù²µ±ð²Ô, thank you again, however regarding the twsactivex?api the data input is all coming from the excel cells and transformed accordingly by the demo program. This issue that I currently have its happening on the demo Excel provided by IB and I did check the function and it gets the conditions well parsed, the issue comes after sending the order?
to the TWS?using the Api.Tws.placeOrderEx function?
anyone in this group, please, do you know if it is possible to debug the placeOrderEx function? Or is it better to contact IB and report the potential bug on their API?
Thank you El mar, 1 feb 2022 a las 19:40, ´³¨¹°ù²µ±ð²Ô Reinold via (<TwsApiOnGroupsIo= [email protected]>) escribi¨®:
We might be talking about different layers.
I was referring to the order and layout of the byte stream TWS expects to receive since that currently causes data format errors in TWS. And in that stream, trigger method is an integer (e.g. the index into the array of friendlyNames).
In the ProceCondition object, triggerMethod is an enum/int so that the conversion from friendlyString to enum/int has to take place somewhere between Excel and the client API.
´³¨¹°ù²µ±ð²Ô
On Tue, Feb 1, 2022 at 12:12 PM, joanmarcel119 wrote:
Thank you ´³¨¹°ù²µ±ð²Ô, however?I've looked into the code of the API and it takes any of these as string argument:
?
? ? ? ? public static readonly string[] friendlyNames = new string[] { "default", "double bid/ask", "last", "double last", "bid/ask", "", "", "last of bid/ask", "mid-point" };
?
? ? ? ? ? ? var fName = CTriggerMethod.friendlyNames.Where(n => cond.StartsWith(n)).OrderByDescending(n => n.Length).FirstOrDefault();
? ? ? ? ? ? MessageBox.Show("fName: " + fName);
?
and I'm confirming I get one that is valid
El mar, 1 feb 2022 a las 19:00, ´³¨¹°ù²µ±ð²Ô Reinold via (<TwsApiOnGroupsIo= [email protected]>) escribi¨®: We don?t have experience with the Excel plugin, but maybe this helps anyway.
When a PriceCondition is transmitted to TWS, fields must have the following order order and types:
- UTFString conjunctionConnection as "a" for AND, "o"? for OR
- Boolean isMore
- UTFString prrice
- Int conid
- UTFString exchange
- int trigger with a value of 7 for condition "last of bid/ask"
The exact byte layout for .
The trigger option codes are:
- 0 = "default"
- 1 = "double bid/ask",
- 2 = "last"
- 3 = "double last"
- 4 = "bid/ask"
- 7 - "last of bid/ask"
- 8 = "mid-point"
´³¨¹°ù²µ±ð²Ô
?
?
|
Re: Adaptive Algo order with relative price
Maybe it is possible to use this also with other order types. I don't trade manually at all so I have no experience with the TWS and just saw yesterday the link I posted below and there it's all about adaptive algo orders. Also as I I understand it the limit price should be moving with the bid/ask. So it would not be a one time calculation at order entry but adapting the limit dynamically to keep it at the chosen offset (this is what I'm interested in).
However I will have a look at the REL orders. Thanks for the suggestion.
|
Re: Adaptive Algo order with relative price
FWIW, some pegged orders such as "REL" allow using dynamic offsets relative to bid/ask to price the order. They are listed among simple order types in the API docs. I haven't ever used them though. I could be wrong but the feature you are referring to is most likely just a user interface convenience of the Order Entry dialog, which is a more hands-on variant of the Order Ticket. It calculates a fixed price immediately and it actually works for any order types rather than being limited to the adaptive algo.
|
Re: how to pause execution
That is correct. I was focusing on part of the IBKR TWS documentation where they say that "a cancel request is submitted to the exchange" when you pause an order. So you could mimic that if you keep the original order object, cancel the order (instead of pausing), and place it again at a later point in time. You would have to assign a new orderId, though.
But you are correct that this is not identical to what TWS can do and your "paused" order would have a final status of "Cancelled". And there are probably other major differences.
II did a quick test and it appears that TWS changes and reports the status for a paused order from "Submitted" to "PreSubmitted" and back to "Submitted" when you end the pause:
- Limit order with unreachable limit price placed in TWS --> orderStatus:OrderID:-115:PermID:991541289:Submitted
- Order "paused" in TWS --> orderStatus:OrderID:-115:PermID:991541289:PreSubmitted
- Order "submitted" in TWS --> orderStatus:OrderID:-115:PermID:991541289:Submitted
- Order "paused" in TWS --> orderStatus:OrderID:-115:PermID:991541289:PreSubmitted
- Order "cancelled" in TWS --> orderStatus:OrderID:-115:PermID:991541289:Cancelled
|
PurpleIce
Despair