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)
This is not just a simple programming error to be addressed. Putting the enumeration in its own namespace solves or prevents a very important and common problem with other indicators.
To step just a little bit into techie territory (sorry, I'll be brief ):
1. An "enumeration" (or "enum") is a programming thing that can only have a value specified in a list. For example, when you click on a drop-down box labeled "MA Type" in an indicator's settings, and see choices like "SMA" and "EMA", that's an enumeration. You have only the listed choices, and you have to select one. They're handy things.
2. Names like "MAType" are real common in indicators. In the PAS indicator, there's an enumeration called "SwingType". That's going to get used by another indicator eventually, too.
3. If programmers put all the enumerations for their indicators in separate "namespaces", then it doesn't matter that another indicator is using the same name; there cannot be a conflict with enums having the same names because the names don't live in the same place, so to speak.
4. If programmers put them in the common ("global") namespace, then there will eventually be a conflict. For example, if you already have an indicator that uses an enum named "MAType" (pretty common), and if you then download another indicator that also uses the enum name "MAType", and if they both place their enums in the common namespace, you will find the new indicator can't be imported. The two indicators simply cannot coexist on the same computer. You also see this in new versions of the same indicator.
The only way to fix this problem is for someone who knows the issue to go into one or the other indicator and hack it to eliminate the name conflict. But only after some gnashing of teeth and intemperate words by the user.
Now, I guess you had the same gnashing and so on when you were trying to get your strategy to use PriceActionSwing, until you could find someone to fix it. The problem you had was that the strategy could not access the SwingType enum, which was isolated in its own namespace, basically to prevent its overlapping into another indicator's or strategy's space.
So basically, "fixing" it so your issue would be eliminated would open it up to the other issue of potential conflict with other indicators. Neither of these are good, but you have to pick one or the other. That's why this isn't a simple error to be repaired; it's a design decision that means you avoid one problem but may end up with the other.
I assume that when support fixed the problem for you, they put the SwingType enum into the common global namespace. That fixed one issue, but it also means that if you download another indicator that uses an enum called "SwingType", and if it also places it in the global namespace, you will have a conflict between them, which will have to be fixed by someone.
Life ain't fair, but there it is.
I hope this post didn't go on for too long or wasn't clear. It's hard to explain this stuff sometimes, but it's good to know why something happens, and the pro's and con's of changing it, and whether it's actually an error.
At least, I hope all this now makes more sense to you.
Excellent explanation it seems to me.
It raises the question of why NT doesn't give each indi (instance)
its own namespace.
Would there be any disadvantages to that, beyond perhaps memory
hogging ?
Sezor
The namespace is purely a programming issue. There are no memory implications, really. It's not "space" in that sense; it's more like whether a program can see a value or not.
Normal programming practice outside of NT would generally be to keep namespaces separate, to avoid possible name conflicts. In writing indicators, a programmer certainly can create a separate namespace for his/her enums, and @dorschden , the original programmer of PAS, did that. I think this is usually the better way to go.
Rachel's issue shows that there may be advantages to making them available to other strategies/indicators if you want to be able to use an indicator in another indicator or a strategy, for example, which NT does let you do.
But then the other side of the two-edged sword cuts you.
As to how to avoid both issues, from a programmer's standpoint that's easy: you keep the namespaces separate and you add the namespace name to your "using" statements (sorry, more technicalese, for the programming community ) in the indicator/strategy that you want to access it. (You have to add it to the "using" statements in the indicator that it's written for, too, which PAS does.)
From a design viewpoint for NinjaTrader, where you want a non-programmer user to easily incorporate an indicator into another, it's not so easy to see how to do it. I believe that the native NT indicators all use the global namespace for enums -- in any case, that's the practice they encourage (per the comment Rachel got from Ninja support) -- I assume because it's an easy way to allow sharing them.
As I said, these are design issues, and you make choices to get what you want, recognizing there are tradeoffs.
But first I want to thank @Silvester17 for answering a lot of questions in this thread and @Tasker_182 for answering some coding questions and requests. I really appreciate it a lot!
If you mean the AB=CD pattern, then use the PriceActionSwingPro version and set in the (Swing) Feature category the setting "ABC Pattern" to "Long_Short".
This alerts are implemented in the new version.
The divergence in the PAS is spotted exactly after this rules and I believe they work correctly.
Sorry, I don't will implement this requests. Maybe somebody else will do it.
In the new version you can set the color for each swing type separately, so you can set e.g. the colors for high swings to the same color as the color of the zig zag lines.
Check out the new version. But you have to uncomment all the "GomCD" regions in the code and compile the script again first. You find this under the setting "gomCDCurrent".
This is possible, but you or somebody else have to code it. You simple check if you are in the current session and if not skip the draw statements.
The PAS indicator is only available for NinjaTrader. I have a MT4/MT5 version but I'll probably don't make it public.
It is possible to track the swing development rather easily but you have to code it yourself or find somebody else. If you just want a triangle to draw when the first indication was, you can use the "swing switch" setting in the new PriceActionSwingPro version. And in the code you give the draw statements a unique tag id. You would change "DrawTriangleDown("DnSwingStart", false, 0 ..." to "DrawTriangleDown("DnSwingStart" + swingLow.Counter, false, 0 ..." and the same for the up triangle. Just search the code for this statements, change them and compile them and you are have what you wanted.
Use the "swing switch" alert in the new PriceActionSwingPro indicator.
The new version can also calculate the swing based on the close values and calculate the swings based on ticks. Check the "Parameter" category.
You can do this rather easily by yourself. In the new version change the file PriceActionSwingBase add at the end of the "CalcDnSwing" function a similar "DrawText" statement like all the other output text statements. You can copy an existing one and just give it a different tag name and change the output to e.g. "(swingHigh.CurVolume/swingHigh.CurDuration).ToString()". Do the same for the CalcUpSwing function. Something like this should work.
But @Big Mike has to upload it first. Once he has done that, he'll probably post a message here in the thread and then you can check out the updated version.
I Changed the code structure - so if you use it in strategies or in other indicators, make sure you have a copy of the old version. With the new code structure it is easier to use the swing functions and values in strategies or other indicators.
Added swing tick and swing percentage calculation.
Added swing calculation based on close values.
Added different alerts.
Added risk management tab.
Added, changed and improved some other things.
I didn't tested it extensively, but I expect everything to work.
Comments, errors and suggestions are welcome!
The alert sound files are attached in a 7z archive. Extract and put them in "C:\Program Files (x86)\NinjaTrader 7\sounds".
The market analyzer output hasn't changed, but you have to use the new template to get all the settings of the PAS indicators. Put the market analyzer template in "C:\Users\user name\Documents\NinjaTrader 7\templates\MarketAnalyzer".
This is an amazing piece of work. I have been the blind squirrel on this so thanks for whipping a nut at me!
This what I downloaded is the "old" version, do I have that right? Mike will notify when the "new" one is in the downloads section? I can add anaKVO to the Divergence piece?
Wow Santa, I hope you liked the cookies and beer I left for you. Thanks guys.
):
