I am looking at certain old features /limitation in NT7 that hinge around strategies that are derived from a base class which was derived and exported from NT7......
1. visibility of the indicatorbase NSWrappers to derived classes....
2. Exceptions - how you have to workaround the methods such as ADD(indicator) and when it causes an issue... and exception.... due to the scope and context of which NSWrapper method is used....
3.Is it possible to negate the need for the loose cs file to be deployed with compiled dlls?
Question:
Why is it not possible for an assembly to use the methods nt generates into the indicator? why is the loose file required to ship with a compiled dll?
Because these are compiled into the scope of the indicator and strategybase namespaces at compile time....
But why do that?
Main Question:
Consider if NT compiled down the custom strategies to a seperate DLLS for each major feature object class etc and
NinjaTrader8.Custom.Strategys.dll
NinjaTrader8.Custom.Indicators.dll
NinjaTrader8.Custom.BarTypes.dll
and NinjaTrader8.Custom.Indicators.dll contained all indicators as compiled -with code generated only for the indicator scope/namespace. and did not do it for strategy - or market analyzer.....
Maybe none of the above is an issue in NT8... except the visibility of NSWrappers methods
ultimately the problem is this in NT7 - Exceptions and work arounds - so im trying to think if i can suggest something for NT8....
i can see the code is hard to change in the object model.... so you can use the syntax EMA(10) from anywhere
public partial class Indicator : IndicatorBase
public partial class Column : ColumnBase -
public partial class Strategy : StrategyBase
all have the NSWrappers in two places
1.open source indicators
2. with compiled indicator dlls
it seems to me that it should be possible someother way.....
no params
#region NinjaScript generated code. Neither change nor remove. // This namespace holds all indicators and is required. Do not change it. namespace NinjaTrader.Indicator { public partial class Indicator : IndicatorBase { public static EMA EMA() { return EMA(Input); } ..... } } #endregion etc
Static?
#region NinjaScript generated code. Neither change nor remove. // This namespace holds all indicators and is required. Do not change it. namespace NinjaTrader.Indicator { public partial class Indicator : IndicatorBase { public static EMA EMA(int period) { return EMA(Input, period); } } } #endregion etc
Virtuals which are overridden in the loose cs file?? to negate need to code it all again?
#region NinjaScript generated code. Neither change nor remove. // This namespace holds all indicators and is required. Do not change it. namespace NinjaTrader.Indicator { public partial class Indicator : IndicatorBase { public virtaul EMA EMA(int period) { return EMA(Input, period); } } } #endregion etc
for compiled deployments
1. but what about the loose nswrappers - what if you remove this- why can't we view the internal indicatorbase methods exposed by the dll if the dlls are referenced....
2. why do compiled base class and derived classes have an Exception when using the Add() method on init....
Anyway here is the pattern to get around it in NT7
Scenario
A deployed referenced Strategy compiled foundation class
A series of open source files that reference it:
the problem is:
public abstract class AwesomeStrategyBase : Strategy { protected override void Initialize() { Add(indicatorX(10)); } }
public class Strategy1Y: AwesomeStrategyBase { protected override void Initialize() { base.Initialize(); // Problem 1 Exception caused in base class on Add(indicatorX(10) ///Problem 2 Compiler Error IndicatorY(Period in) not reachable Add(indicatorY(10)); } }
#1 compiled dll
public abstract class AwesomeStrategyBase2 : Strategy { protected override void Initialize() { BaseClassIndicatorsSetupAndAdd(); } public virtual void BaseClassIndicatorsSetupAndAdd() { Add(IndicatorX(10)); } }
#2 //Open Source file deployed to NT Strategy folder
public abstract partial class AmazingStrategy : AwesomeStrategyBase2 { protected NinjaTrader.Indicator.ADX _proxyIndicator = new NinjaTrader.Indicator.ADX(); public MTDoubleShotStrategy() { _proxyIndicator .Input = Input; _proxyIndicator .Strategy = this; } public override void BaseClassIndicatorsSetupAndAdd() { Add(_proxyIndicator.IndicatorX(10)); //required to use the NSWRappers context compiled into the local open source strategybase and indicatorbase - prevents errors on adding to a chart.... if called in base compiled file.... cross threading or something? } other methods same as strategybase ..... ETC }
public class AmazingStrategyCrossover : AmazingStrategy { private EMA fastMA = new EMA(); protected override void Initialize() { base.Initialize(); //indicators NSWrappers not visible at this level use _indicator. fastMA = _proxyIndicator .EMA(this.FastMAPeriod); Add(fastMA); } [GridCategory(" Indicator Parameters")] public int FastMAPeriod { get { return fastMA.Period; } set { fastMA.Period= value; } } }
#4 Open Source file in Strategy Folder with a copy of the NSWrappers method - MORE WORK
public class AmazingStrategyCrossover : AmazingStrategy { private EMA fastMA = new EMA(); protected override void Initialize() { base.Initialize(); //indicators NSWrappers not visible at this level use the method defined at this level fastMA = EMA(this.FastMAPeriod); Add(fastMA); } [GridCategory(" Indicator Parameters")] public int FastMAPeriod { get { return fastMA.Period; } set { fastMA.Period= value; } } public Indicator.EMA EMA(int period){} public Indicator.EMA EMA(Data.IDataSeries input, int period) { return _proxyIndicator .EMA(this.FastMAPeriod); } }
Comment