Keyboard Shortcuts
Likes
- Twsapi
- Messages
Search
|
Re: twsapi: Re: To grozzie2:
Nick
Now those id's are allocated, and safe to use,Well, it's probably less painful to set up your own id server. Have one app that requests id's from tws and have your trading software request id's from the id server instead of tws. Yes, it's another layer of stuff but I suspect it's the only reliable way to get around the problem you are facing. |
|
Re: To grozzie2:
bee_jay_61
timerMaybe in this case the multimedia timer or a high-resolution tws.could help you.The real answer is to understand how to get id's allocated from Everybody is under the mistaken impression, the NextId callback isa block, then the nextid will make a jump from what it was, to thenext one after your block. Now those id's are allocated, and safe touse, the only issue, is dealing with the problem of multiple allocationsbeen placed. If you are doing trailing stops, it's easy to 'accidently'OK. I never placed more more than one order within a millisecond. But I can?t imagine that the use of a hi-resolution timer wouldn?t solve all these id problems. The GetTickCount function uses the PC Clock. So why don?t you use the QueryPerformanceCounter? It uses the PC's clock counter but it reads the current value of the countdown register in the timer chip to gain more accuracy. So you can go down to less than 1 microsecond (depending on your machine speed you can even count the nanoseconds). To place an order needs a least 5 to 10 microseconds - I guess. So you will never have duplicate order id?s. At least I can?t believe that. |
|
Re: To grozzie2:
Maybe in this case the multimedia timer or a high-resolution timerThe real answer is to understand how to get id's allocated from tws. Everybody is under the mistaken impression, the NextId callback is the one to use, it's not. You use the request ids call, to reserve a block, then the nextid will make a jump from what it was, to the next one after your block. Now those id's are allocated, and safe to use, the only issue, is dealing with the problem of multiple allocations occuring at the same time. By going this route, there should be no chance of hitting duplicates, and if you start getting duplicate id messages, it's because you are modifying orders before they are actually 'in and working'. You cannot modify an order between the time you call placeorder, and you get the callback saying it has been placed. If you are doing trailing stops, it's easy to 'accidently' modify a stop during this timeframe, if you dont watch out for the specific circumstance. My applicaton allocates a block of 1000 id's when it starts, and due to the potential time lag from requesting more, to actually getting them, I request a new block when I've used up 800 of the 1000. Tonite i've been fiddling with issues during partial fill sequences, I finally figured out a way to reliably get partials from the demo. Load up a buy order for 15 nq, then sit and wait for the offer to show size of 8 or less. Lift that offer with a limit order. If the offer is 1, you'll get a string of 15 individual fills, scattered over approximately 2 seconds. If you have logic to throw in stops and targets on fills, it's an ideal way to test it, because you'll have the initial order in on the first fill, then you have every possible bad timing issue repeat for the rest of them, and your code to update the stops and targets will not go off on every fill, because you'll have orders in the 'pending callback' state. I actually added a bit of code onto the tickprice handler, to 'lie in wait' for the correct time, then let loose the orders to buy/short with as many as the demo will allow. This is an exercise well worth doing, because if your code has any accidental timing dependancies in it, you will find them with this exercise. Once i figured out the way to reliably get partials, what I thought was going to be a simple verify that some handlers were working correctly, turned into anohter session of 'wtf is this thing doing now ??' Options are going to be even more interesting, because we'll have to observe the 1 second limitations. To prevent automated trading, the exchanges mandate the brokers dont accept orders at a rate of higher then one per second on any given customer account for options. Gonna be interesting figuring out just how accurate the timers for this are at ib, and just how much time we will really have to introduce between options orders. I suspect to be safe, it's going to have to be on the order of 1.2 seconds or longer. If your application is going to be doing groups of options orders, it'll need to set up an order que, and then peel orders off the que at the maximum allowd rate, to forward them for handling. |
|
Re: To grozzie2:
bee_jay_61
Maybe in this case the multimedia timer or a high-resolution timer
toggle quoted message
Show quoted text
could help you. --- In twsapi@y..., "grozzie2" <grozzie2@y...> wrote:
Order Id: I use GetTickCount.That'll only work, if you dont have lots of orders going in on the |
|
AW: twsapi: Authomated Trading for TWS
¿ªÔÆÌåÓýTradestation and Wealth-Lab
|
|
Re: twsapi: Authomated Trading for TWS
marwanco
¿ªÔÆÌåÓýI have a question: ? Which system/software develops trading signals automatically in real time? ? Thank you ? ? -----Original Message-----
From: Shukrainternationals [mailto:shukrainternationals@...] Sent: Sunday, 14 July 2002 12:42 AM To: twsapi@... Subject: Re: twsapi: Authomated Trading for TWS ? I have two questions about TradeGaurd. I have sent these questions to the developer of the program also. Here they are: 1. In what way this program is better than IB Dde.xls platform where you can place orders also? 2. In Ib platform, you can at least send (write in to appropriate cells) an order that is generated from other system such as TradeStation 200i. For a trader, and that to a scalper, there should be supporting system that tells him when to buy and sell. While TraderGaurd is good, it does not take orders from another system which develops trading signals automatically in real time (or, does it?). l
twsapi-unsubscribe@... Your use of Yahoo! Groups is subject to the . |
|
Re: OCA Orders
CarlErikson
Here is what IB says in their user's guide about OCA orders:
--------- A One Cancels All (OCA) order is a combination of separate orders that are worked in conjunction with one another in the marketplace. A customer enters orders as part of an OCA group, and when an order is executed, the remaining orders in the group are canceled. If an order is partially executed, the remaining orders in the group are reduced proportionately to the amount that was executed. If an order is canceled before execution, the remaining orders in the group are canceled. --------- So my example with the partial fill of 43 shares seems to be correct given the above description. Not that you would do this, but suppose you put in a 200 share target and a 100 share stop (with the same OCA). If you got a 100 share partial fill of the 200 share target, it appears that the stop would go away completely (assuming I understand what "proportionately" means). I.e., 100 shares would be subtracted from each order that shares the same OCA string. Good luck, Carl --- In twsapi@y..., "grozzie2" <grozzie2@y...> wrote: forceFurthermore, suppose I am long 100 shares of MSFT andOk i just tried this with nq contracts, but it's impossible to a partial fill, so I tried it by modifying the size of the targetorders, see if i can get a partial to happen on a target, and see what |
|
twsapi: Re: Newbie Help on Code !!
larrysy.geo
Right, this board REALLY works as intended. Thanks to Scott.
Larry P.S.: I have already modified my project to handle multiple simultaneous OCA orders. Next target is to include the order entry routine into my project and also some error handling. --- In twsapi@y..., "marinindextrader" <marinindextrader@y...> wrote: The board works....killer glad you got what you neededversion time -with OCA to the files section. Only does one OCA group at a orderbut already functional for me. help(i.e.Tws1.oca = "1234"). meout? |
|
twsapi: Re: Newbie Help on Code !!
marinindextrader
The board works....killer glad you got what you needed
toggle quoted message
Show quoted text
The squeeky wheel gets the grease Who'd u thunk? Have a nice weekend Scott --- In twsapi@y..., "larrysy.geo" <larrysy@m...> wrote:
Dan, my problem is solved !! I have already uploaded the version |
|
twsapi: Re: Newbie Help on Code !!
larrysy.geo
Dan, my problem is solved !! I have already uploaded the version
with OCA to the files section. Only does one OCA group at a time - but already functional for me. Thanks, Larry --- In twsapi@y..., "Daniel Rosen" <drosen@g...> wrote: Scott,(i.e. Tws1.oca = "1234").me out? |
|
Re: OCA Orders
Furthermore, suppose I am long 100 shares of MSFT andOk i just tried this with nq contracts, but it's impossible to force a partial fill, so I tried it by modifying the size of the target order manually. That does not automatically modify the size of the stop. I'll play with the demo here a bit, doing maximum size orders, see if i can get a partial to happen on a target, and see what happens to the stop. |
|
Re: OCA Orders
Furthermore, suppose I am long 100 shares of MSFT and Now that is good to know. We've not had much success in forcing partials on exit orders, so, haven't been able to see that, therefore we have played it safe and made our stops resize on thier own on a change in the postition size. I'm gonna experiment with that a bit here, i wonder if it goes the same in the reverse direction, ie will the stop size up if i size up the target order, when they are part of an oca group ? I have noticed i get 2 reports every time I size up a stop as we add size to a target and stop. I wonder if the first report is due to tws doing it already, and then i do it again. Will let you know. |
|
OCA Orders
Carl Erikson
You can place OCA orders in the C++ socket version.
It is part of the Order structure that IB provides. Also, the Java socket version allows OCA orders as well. Looking at the Visual Basic ActiveX documentation, I notice that the OCA field is an "ActiveX property" whatever that means. All I'm saying is that I can submit OCA orders in C++ and Java so either you can submit them in Visual Basic or you should tell IB to add that functionality. Furthermore, suppose I am long 100 shares of MSFT and I put in a target and stop using OCA. Suppose I get a partial fill of 43 shares at my target. The TWS automatically resizes both parts of the OCA order to the remaining number of shares, in this case 57. Suppose after getting the 43 share fill, that the price falls and hits my stop. I am in 57 shares at that point and the stop will be for 57 shares. Carl __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes |
|
Re: Newbie Help on Code !!
skunktrader2001
--- In twsapi@y..., "marinindextrader" <marinindextrader@y...> wrote:
But the questions remains...How do you flag an OCA group whensending to/through the TWS?is their any refrence in my documentation as to OCA?public class Order { .. .. // extended order fields public String tif; public String ocaGroup; public String account; } If multiple orders are submitted each containing the same string "trade1", or "12dfe" or whatever, then the first order to fill will automaically cancel all the others. You can place both a profit taking order and a stop loss order and execution of the first will automatically cancel the other. |
|
To grozzie2:
bee_jay_61
FWIW, i've given up completely on all the ib supplied code, and nowI did the same in Delphi and I think to use the sockets directly without wrapper classes or the ActiveX is the best way. Order Id: I use GetTickCount. Read my last posting. |
|
Re: twsapi: Asset US format information
skunktrader2001
--- In twsapi@y..., "marinindextrader" <marinindextrader@y...> wrote:
OK but answer this... Example 2 shows the syntax to request data for a list of symbols Example 4 shows the syntax to request data for all symbols A*, B* etc. It is NOT possible to request '*'. Frankly I dont give a rat's Pitutey about Qchart's add on garbage...records down [OHLC], ostensibly leave open the query, and have an openthat lets me update my array when the period closes/opens... Examples of requesting data in any compression (tick, minute, x minute, daily etc) for a user defined date/time range. I don't know what the ActiveX/VB support is like but the C interface is reasonably straight forward. |
|
Re: twsapi: Re: Newbie Help on Code !!
Daniel Rosen
¿ªÔÆÌåÓýScott,
?
OCA is
a property of the ocx.? Set it before you place the order (i.e. Tws1.oca =
"1234").?
?
..
Dan
?
PS. I
sent you a private email about QCharts/QFeed.? Can you help me
out?
|
|
Re: Newbie Help on Code !!
--- In twsapi@y..., "marinindextrader" <marinindextrader@y...> wrote:
But the questions remains...How do you flag an OCA group whensending to/through the TWS?is their any refrence in my documentation as to OCA?The oca group is one of the strings within the order structure/object. I dont know about the ActiveX thing, but at the lower level, within the order structures is a string for the oca group name. Just fill it in before you place the order. FWIW, i've given up completely on all the ib supplied code, and now have my own stuff deal directly with the sockets. On the c++ wrappers they provided, the oca group is one of the CString objects within the order itself, so I would expect it's a property of the activeX version. By re-writing everything, i've narrowed down the problems to one single outstanding problem, for which there is no cure short of fixing tradeworkstation. I'ts on the 'nextid' stuff. Using the last one given to you from the nextid callback is NOT safe, remember this, that same number has been given to ALL programs talking to tws. The safe way, is to request a block, then wait, and see that the next one it says, is that far beyond the block you requested. Now you know, the block is yours, and wont be used elsewhere. The problem is, if 2 clients request at the same time, there's no way to tell, which client got which block, at least that's how it'll work with way the original c++ wrappers were built, so i'm assuming the logic inside the ActiveX is just as broken. We've redone that logic as best we can, and it 'appears' to be safe so far, but only time will tell. |