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)
What I mean is, apart from connection/overfill/rejection, which are largely handled in unmanaged, what complex stuff stops you enhancing managed to include longstop/shortstop bracket without too much trouble? I'm trying to understand what your issues are.
Can you help answer these questions from other members on NexusFi?
From what I understand, it's overfills that are the problem - not being able to cancel out the other stop on a fill where the bracket is tight. But let's hear it from NinjaTrader direct - I'm not speaking for them.
You can discover what your enemy fears most by observing the means he uses to frighten you.
Thanks for the reply. I wasn't so much looking for examples, more opinions. Was switching to unmanaged a good thing, was it easy, do you always use it now, even though managed might do what you want, are there pitfalls not mentioned in the NT docs.
i find that the extra lines of code required resulted from having to flush out a more granular set of rules to manage the trade. the implementation was no more or less easy/difficult than coding managed. the added difficulty comes with the opportunity to be more precise. and in our particular case, it resulted in fewer lines of code overall, oddly enough.
yes
managed did most of what i needed, but switching to unmanaged made it much easier to write re-usable code blocks. and that is the way i like to develop, so i switched and haven't really looked back.
sorry, you guys are right. i mistook "unmanaged" for "advanced order handling" at first. and my example better demonstrated why i used AOH instead of SetStopLoss().
we did eventually migrate from managed to unmanaged because the strategy was multi-tiered and each tier could have multiple stop-handling triggers/rules. it simply became easier use our own "wrappers" with the unmanaged methods rather a couple of bloated switch() statements.
so maybe it's more correct to say i use my own managed version of the unmanaged setup? sorry for muddying the waters. i do still really appreciate NT allowing us to "get creative" :-)
Unmanaged approached covers the requirements of strategy developers to submit multiple opposing entry orders simultaneously. We felt that exposing this unlimited approach was a smarter decision (for both business and practical reasons) than trying to fit it into our managed code base.
I totally agree with eman. I am in the transition from managed to unmanaged, after playing with managed mode for a few months, with much frustration.
Reasons for the transition:
1. As users of NT, we do not know what is happening behind the managed solution. It is something that adds some protection but also asserts a lot of restrictions.
2. My aim is unattended trading, which means a lot of rare scenarios must be dealt with in the code. I have heard from TradeStation (perhaps NinjaTrader has the same view?) that the aim of strategy trading is to relieve traders from repetitive works that can be done better by computers, which is a different perspective. In reality, error-handling, which is highly critical to unattended trading, can only be dealt with on a case-by-case basis, since a lot depends on the broker and the exchange, and factors out of control of platform companies.
3. Due to restrictions under managed mode, we are essentially trading freedom for some level of protection. That means in many cases, we must "work-around" the restrictions, which can be a nightmare for software maintenance and code reuse, and in many cases, can make code more complex.
My current view of this issue is that if you are experienced in programming and you want fully-automated trading, unmanaged seems to be the only way to go. With that said, I have only programmed in the unmanaged mode for a short period of time, not long enough to discover serious issues. Experienced programmers please chime in and share what you find.
I've now started with unmanaged, and it does seem the way to go. I deliberately started with something hard - bracketing, stop and reverse and all handling partial fills. It seems to be working fine, and I can see that I'll stay with unmanaged.
Just seems a shame that each of us doing it are reinventing the wheel and coming up with a load of reusable code which is probably fairly similar.
I like writing my own code, and it's a good way to keep control and knowledge of what's going on, but I would have seriously considered buying a well designed library to handle it all.