Logically, this is not correct...some items for consideration: 1) A position is created from one or more orders Thus, there is a one to many relationship here. 2) A position can have one of these 4 statuses: a) open long b) open short c) closed (flat) d) reversed to long e) reversed to short The last two are a bit tricky to understand but easily understood: if you are long 2000 shares, and then sell 4000, you have reversed to short. So a single order can be related to zero (no fill), one or two positions. Get it ?
I was just talking about positions as far as programming is concerned. A position is a state. What's the position in IBM? (300) ... 0 ... 400. The orders you use (manually in the UI) to build into this position won't affect your future orders. You do not need to know anything about those closed-orders ID's in order to send new ones.
Thanks to you both for your replies. I can see that I didn't explain myself correctly, sorry about that. I understand the distinction between position and order in Sterling, but unless I misunderstand the process, if I want to close a position--forget about adding to it for now--I need to do so by placing an order (Sell or Cover) to which an orderID is associated. My understanding is that whatever order you place and for whatever reason, it needs an order Id of some kind associated with it before the order is sent. That makes sense. Is that same orderID used for opening a position then necessary to close it? That's my question. To cancel an order (not a position) or update it, I can see where the same order ID needs to be re-used, but is re-using the order ID a determining mandatory element in closing a position? If no, then as long as I have an order ID (client generated) with my closing order then presumably the order will be assigned as per 1) whatever position is opened in that security 2) adjustments rules as per the API doc when the size and/or side of the closing order is different from the existing position in that security. In the case above it doesn't matter that I open the order from the UI and close it from the API with different Order ID's. If the Order ID matters then I need to think about retrieving it in the case above. That's what I'd like to avoid, and the basic reason for the question Thanks in advance for the info Elvis
Maybe this will help: Once an order is closed (i.e. the order you used to get into a position, say buy 100 IBM), you cannot reuse that order ID. You can only use that orderID to modify THAT order. To send a NEW order to change that position (SELL 100 IBM), you must have a new, unique ClOrderID. If you then want to adjust that order before it fills, you need this new ClOrderID that you created. ...that is, if you choose to use a ClOrderID. You can leave it blank, but then you won't be able to access that order again until you somehow get the RecOrderID back, either from an order update or by requesting order status.
Got it. It's clear now and that's exactly the explanation what I was looking for. Thanks to you and syswizard for taking the time to reply. It's much appreciated. Elvis
You ain't kidding. Started out as a small project to attach stop orders to open positions and now I'm building PredatorPro: the Kludge Edition
Anyone know of any publicly available c++ wrapper classes which implement Sterling's COM objects? I've never worked with COM before, looking through the sample STIEventDemo program it seems pretty convoluted. Or maybe have a link to a decent implementation guide? Thanks
The C++ examples are minimal, so I suggest using VB instead (which is what I did). Even though I've barely ever worked with VB, this actually worked out pretty well as the Microsoft editor for VB (coupled with a lot of Google searches) makes it fairly easy. On the other hand, there are a lot of API features with little documentation save the name of the method itself; and, moreover, the use of more than one order ID for different purposes is far from intuitively obvious. THESE issues took me quite a bit of time to resolve, and there's probably no way around them save for experimenting yourself and/or posting to this message board or asking Sterling people, who are in fact pretty helpful in my experience. I agree with Nitro's earlier post that a pure socket interface to Sterling would make life a lot easier. In fact, I essentially implemented that myself -- what I developed to the Sterling API is a multithreaded server whose only job it is is to take orders for Sterling and pass Sterling callback info back info via two sockets, one for each task. It crashes maybe once a day on average (for unknown reasons), but I also wrote another script whose only job it is is to restart the app when it crashes. It's bubble gum and duct tape, but once in place it seems to work pretty well.
What exactly did you do ? You hooked some API functions in the DLL ? I did something similar, I created a little re-route of the incoming packet data, filter the packets for quote/order confirms etc, open up a socket and use this socket to communicate with my own program (I was also inspired by Nitro's post, lol). So in short, when the Sterling trade pro initializes, I would let Sterling PRO open up a socket and then would forward the incoming packets to the socket, just before the packets are being processed by the sterling platform itself. However, I ran some test to see how it performs, i used a highperformance timer and was a bit disappointed when I saw that the difference was most of the times something like 0,0000001 second between the data received via COM and the socket. Sometimes the COM was even faster ! So I stopped doing that, since the whole process is far more prone to errors than the COM stuff. Not sure why I got such disappointing results, I KNOW that COM is damn slow (i've tested it thorougly) and I know it's the most stupid thing STerling could have done (use COM), but that's why I don't really understand the slow performance of the socket ... I think one of the problems was that my socket would sometimes 'group' packets instead of sending them everytime one would arrive. Or, maybe the other side, my bot, would ping the incoming socket for received data on a too big interval (all I know that my bot would receive grouped packets, which weren't received as a grouped packet by the platform). I think it's probably that, since I used a simple Delphi component in my bot, I wouldn't be surprised if it's not made for high speed and that I should code something myself. I wish that sterling would just use damn callbacks, come on, this isn't 1990 anymore. It's damn frustrating that we, as Sterling users, have to go through all this bullshit to compete with other platforms.