ChartStyleType antipattern

[mantak007]

Hello,

I was quite suprised when I saw the ChartStyleType usage for registering new bar types. May I ask why did you choose this style of registering? It's only a matter of time before a user tries to install two different 3rd party bar types with same ChartStyleType resulting in a confilct. Why don't you provide an internal repository with e.g. int RegisterBarType(Type customBarType) method, which would assign the numeric id internally (I suppose you need it somewhere deep in the code).

And another question, why did you decide to have single OnStateChange() for many independent tasks instead of several virtual methods like SetDefaults(), BeforeConfigure(), BeforeHistorical() and similar?

This is quite a big contrast to other modern features you use. It reminds me of old C with global variables or huge switch statements.

Thank you

[NinjaTrader_ChelseaB]

Hello mantak007,

Is this post referring to NinjaTrader 7 or NinjaTrader 8 Beta?
(I ask because this is not posted in the NinjaTrader 8 Beta section of the forums but refers to OnStateChange which is part of NinjaTrader 8 Beta)

In neither NinjaTrader 7 or NinjaTrader 8 is it needed to reference a ChartStyleType in a BarsType file or class.

With NinjaTrader 7, custom bar types and custom chart styles are not supported. It was not intended that coders could write custom bar type scripts or chart styles. Because of this, these use slots that can cause conflicts when the slots are re-used.
There are 15 slots that can be used. Custom0 - Custom9 and Final0 - Final4.

With NinjaTrader 8, custom bar types and custom chart styles are fully supported and will use the class name. No conflict will be possible that I am aware of with NinjaTrader 8.

Using a constant State object allows you to check this state through the script as well as trigger events when the state object changes. This allows for cleaner code as well as a consistent object that can be tracked.