Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
I'm getting a bit sick of managed orders in Ninja and am thinking of switching to unmanaged.
Did anyone do this switch and decide it was really worth it, to the extent that you now always use unmanaged?
I know the pitfalls, and my programming is fine. In fact, I could see the benefit have having a whole seperate class with its own unmanaged order submission, tracking, order states, and shadow methods for position/order/execution update etc etc. Did anyone go down that path?
[as a slight aside, Ninja keep saying that they may enhance their managed approach, but that there's a lot going on behind the scenes and it's a lot of work. well, OK, I can see some of that, but it's sounding to me like they're making it out to be more than it is to not get round to any enhancements]
There is no exaggeration here, the code is complex and thus sensitive to any changes. At the end of the day, the "unmanaged" was introduced for advanced developers who wish to code at the lowest level giving them full creative control. At the end of the day, if you are limited by the managed approach you should go to unmanaged.
The main critical considerations listed are rejections, overfill and connection/resync, much of which is sort of handled in unmanaged anyway.
As an example, I can't really see too much problem in adding the bracket (longstop, shortstop) to managed. One can cancel the other. If one is rejected, you still have to handle what you want to do. If both get filled, it largely means one has acted as stop for the other, which I think would be acceptable or even desirable for most people.
What other complex stuff is to be handled for the bracket, which seems to be the most requested feature anyway?
@Xeno - say i wanted to enter a trade with an initial target of +20 and a protective stop of -10. after the trade moves +5 in my favor, i would like to tighten my stop to -5, leaving the target of +20 un-touched. if the trade continues to move in my favor, after +12 of profit, i remove the target and tighten my stop to +2 and then on each and every uptick, i trail my stop up until the market retraces and takes me out.
this is a hypothetical example that illustrates how i have used the unmanaged approach. hope this helps.
Can I just ask, what part of that example cannot be coded within the managed order scenario?
I haven't tried it, but I would have thought that SetStopLoss() allows you to adjust the stop, and capturing the target IOrder for the SetProfitTarget in the OnOrderUpdate event will allow you to cancel the order. Or is that over-optimistic?
You can discover what your enemy fears most by observing the means he uses to frighten you.
