So .NET isn't backwards compatible (performance-wise) ??? 1 step forward, 2 steps back? That's pretty dumb. But in the end, why would Sterling write an API that 'works' with just 1 programming language? There are plenty of good ways to do this, and they chose a really bad one for the majority of users. I don't understand why they keep accumulating more paying users without actually puting money into improvements. Kinda reminds me of the IBM commercials... stop talking, start doing. We're past bandaids -- Just fire your freaking head architect, dish out the cash, get somebody good and start overhauling this API.
I think you are missing the point. The reason Sterling is average at best is because it is stuck in eight year old technology. On top of that, COM was never meant to be used like it is being used for realtime data processing. What they need to do, like IB did when they realized that COM is toy, is to write a socket interface to their API. Not only does that free you from Micrsoft if you wish, it is far faster and more efficient. nitro
That would be MUCH better indeed. Still, I'd even prefer just a DLL, that would contain all needed function to connect to a server, send orders and would contain callbacks to my event handlers. I don't need interaction with the platform, that only means unnecessary extra delay's
I think they want you to interact with the platform so that you go through their risk management controls.
Oh no, I hear you. I think we're saying the exact same thing. The fact that COM doesn't play well w/ .NET was just a side point. They need to stop sitting on their hands and actually take some action. I'd love to go in and just clean house.... but I can barely even get more than 1 email reply after they don't know an answer to my question. Seems to be working for them... just ignore stuff and it will go away. No problem!
Unless you have an ETP, you are always going through the brokers order router/manager, regardless of what layers you went through to get there. nitro
Totally agree...for realtime stuff COM is dumb...it's so sloooowww. Again, DLL calls are the way to go. Even Excel can handle DLL calls with callbacks. SOOOO....where oh where is Sterling's technical management on this issue of upgrading this old, old API ? Wow, the USA is starting to look like a third world nation technology-wise anymore. Quiet pathetic.
Hi. I hit a little snag in my VBA coding and I'd like to know if the following is possible: Open a position from the UI --> Assigned OrderRecordID by the system Close or add to above position from API with ClOrdID created at close/add-to order time, instead of OrderRecordID I understand the part about automatic adjustments rules from the API doc when the order doesn't jibe with the open position(s). FYI, I'm getting the position info from the RTD server but the OrderRecordID is not retrievable that way and the above is a scenario that I'd like to provide for if it's allowed. Thanks in advance for any info.
I think there's a little confusion between "position" and "order". You say you want to open a position, but assign it an order ID. Positions don't know anything about orders, and are not tied to order IDs. If you "buy or sell some" --> "open a position" and the order fills, the position in no way is tied to the order ID for that order you send through the UI. Once the order if closed, you won't need that order ID anymore. You can then send new orders for that symbol with your own ClOrderIDs. Are you trading through Excel or something? Eric