Ok, I changed the default SortId for KaseBarsType, and I also added two new constants near the top of the file to make it easier for people to change the constants used for NT65/NT7 in the case that they are conflicting with other Custom Bar types.
If you were previously not having issues, the new version adds no new functionality.
The following 2 users say Thank You to aslan for this post:
I just changed mine to 14100 and it works without issue. Aslan, now that you have made a change let me know what the new number is so I can make mine match. For more info on SortOrder for existing custom bars, check the list below:
Median Renko = 13007
NoGap Range = 13400
PointO = 14000 <== this was the conflict
RangeAlt = 3200
Renko = 13000
SbSRenko = 13008
These are the NT6.5 types I checked out.
The following 2 users say Thank You to eDanny for this post:
Yes, same issue here. no historical data on Kase or any other custom bars like RangeAlt, NoGapRange, etc. . . . unfortunately I don't have the older version to overwrite the new one. Can someone please post the older version of KasebarsV4 please.
Not sure what NT is doing, as this bar type should not be affecting other types. Did you try reloading historical data? The only diff between the previous version and V4 is changing the SortId, which you can manually change using the previous instructions.
A few other changes were made also. Not sure why they would have this effect but the previous version works ok. ALSO, now that I think of it, when I was having problems with the Kase bars I also had no historical bars on any charts and had to remove all the custom bar types, not load my workspace and had to rebuild my charts/workspace. Now I'm wondering if it was related somehow. I didn't think about it at the time. Here is the NT forums link. http://www.ninjatrader.com/support/forum/showthread.php?t=31715
The following user says Thank You to eDanny for this post:
Well if you compare the files, there was exactly one functional change made (3 lines of code and changing the SortId to 14123). The SortId and PeriodType were brought out to make it easier to change in case of collisions with other types.
I can not control what f-ing NT does under the covers, but can only try to give you some ideas.
My best guess is NT is using that sortid as more than a sorting id, and uses it somehow when it requests historical bars, and when it changed they got confused due to a bug (yes I know, an NT bug - shocking). In true NT form, I can tell you I did not see the problem here Perhaps, I didn't see it because I don't use the NT history server (notice, how I am still typing after making that last statement, as opposed to NT support).
I also suspect the only people seeing the issue are people that have used the bars with two different ids (loaded V3 then V4 due to a collision)? I would not expect this to be an issue, but I guess NT can not handle it.
In terms of the workspace, that is another place where that id could get stored by NT, so I would also try removing the offending chart, and if that did not work, the workspace itself. Before blowing things away, I would create another blank workspace with a single chart to see if that flushed things out.
I can not offer much more than that. If you need the V3 file, PM me, and I will send it, if you are an elite member.
The following user says Thank You to aslan for this post: