NinjaScript generated code

[gregid]

With tighter integration with VS maybe it would be worthwile to move all the code from:

#region NinjaScript generated code. Neither change nor remove.

to some other shadow file(s) (even compiled dll). This could potentially avoid constant "file has been modified" outside - do you want to reload?" prompts in VisualStudio after every save of an indicator.

[NinjaTrader_Dierk]

I could use some education: what do you mean by 'shadow file'. Just a separate file (we discarded that idea years back to avoid potential issues)? A particular 'technology (I'm not aware of yet)'? else?

[MicroTrends]

With tighter integration with VS maybe it would be worthwile to move all the code from:

#region NinjaScript generated code. Neither change nor remove.

to some other shadow file(s) (even compiled dll). This could potentially avoid constant "file has been modified" outside - do you want to reload?" prompts in VisualStudio after every save of an indicator.

The code is generated internally and compiled with the indicator

establish the parameter input list ( people put parameters in that list in NT7 that should not go there btw)
to add to cache
instantiate and setup the indicator
allow add to a chart
it brings those methods into context of the marketanalyzer, other indicators and strategies... within the custom dll

when you compile and export it the lose .cs file is needed to allow visibility of those access/instantiation methods on that machine - and will be compiled into scope of the strategybase for example.... so you get the nice inline code...

int val=10
SMA(val)[0]

and even more awesome if you set later
val=20
SMA(val)[0]

it loads a new instance... very slick indeed....

What could work is a generic factory method to start and add all indicators
so then just have a method with no parameter just input...

So but what about the parameter list?
thats why the code generated is passed around

or you would have to do this inline

SMA sMA = SMA(Input);
sMA.Period=10;

which is ok but then you got to set parameters and its not as user friendly as

SMA(Input,10)


so the NS Wrappers code is good thing a macro saves you the time to add it

you can compile in VS a file and from NT can create this code yourself - based on the code generated... and add it before compile in VS - use NT to generate it on a dummy empty filer with just the public properties of type ninjatraderproperty

IN Visual Studio
you could simply write a simply post compile script to use reflection or read the code and add the code yourself.... would be my preferred route

Architecture Alternatives
In my mind the above scenario of passing around open source cs to compile into the strategbase and custom dll on a target machine when open source is not provided could be avoided altogether..

If NT compiled down the custom strategies to a seperate DLLS
NinjaTrader8.Custom.Strategys.dll
NinjaTrader8.Custom.Indicators.dll
NinjaTrader8.Custom.BarTypes.dll


so
MicroTrends.NinjaTrader8.Custom.Indicators.dll
sits alongside
NinjaTrader8.Custom.Strategys.dll

and strategies compiled from open source code in that context would have visbility to th referenced side by side assembly to the factory/methods for the indicators and not need the NS Wrappers to be provide as loose cs

This would provide massive benefits...

a class compiled on top of
NinjaTrader8.Custom.Strategys.dll
NinjaTrader8.Custom.Indicators.dll
NinjaTrader8.Custom.BarTypes.dll

and output as

MyNTLibrary.NT8.AwesomeStrategyFoundation.dll

and used as a base class to deriver strategies of type

MyAwesomeStrategy1.NT8.dll derived as

public Strategy :AwesomeStrategyFoundation
{
}

Would be able to reference and see the same scope of indicators and avoid all the issues with NT7 architecture whereby it is neccessary to add some open source files to bring them into context for the ADD(indicator):

So if you do that then it would be simpler to say the least - you would still need a macro to write the NS Wrappers for indicators for compiling into the class -

but you could remove all the other parts such as the lose NS Wrappers and avoid the need to perform workarounds as all is in the same scope of context as a normal side by side... group loaded into the assembly would be


Stopping all the Antivirus messages and webmaster tools incorrectly messing with downloads and installs etc...

and avoiding the problems with baseclass strategies loading via ADD(indicator)
and derived strategies loadin an Indicator via ADD(indicator2) - casuing an explosion... in NT7....

becuase the context and scope of code is wronge- you ahve to late bind it effectively /defer adding of the indicators in the base class by using an overload and calling that from the scope of the compiled derived class - basic stuff for commerical coders but fiddly and complex for most developers - and not as slick...

[NinjaTrader_Dierk]

Sorry, I don't follow. Where should the wrapper code (there is no way around of having this code) go?
a) separate file (we discarded that)
b) else?

Also:
- splitting up the NinjaTrader.Custom project in separate assemblies makes no sense. We discussed that internally several times already.
- run time parsing of properties through .NET reflection does not work, since it would require compiled code. But compiling requires the said wrappercode (think of indicator A using indicator B) -> hen and egg problem

Could you pls reply in a simple as possible way so I properly understand your suggestion? Thanks

[MicroTrends]

I could use some education: what do you mean by 'shadow file'. Just a separate file (we discarded that idea years back to avoid potential issues)? A particular 'technology (I'm not aware of yet)'? else?

partial class designer file?

when VS detects a file watcher change and modifications it will flag to reload regardless where that is

[MicroTrends]

Sorry, I don't follow. Where should the wrapper code (there is no way around of having this code) go?
a) separate file (we discarded that)
b) else?

Also:
- splitting up the NinjaTrader.Custom project in separate assemblies makes no sense. We discussed that internally several times already.
- run time parsing of properties through .NET reflection does not work, since it would require compiled code. But compiling requires the said wrappercode (think of indicator A using indicator B) -> hen and egg problem

Could you pls reply in a simple as possible way so I properly understand your suggestion? Thanks

splitting up the files into side by side dlls allows a more flexible development experience and more extensible architecture as discussed below when using derived classes and things...etc but we can live without it as there are ways around as detailed below... it certainly would make life easier.... to have them split into seperate files...

[MicroTrends]

splitting up the files into side by side dlls allows a more flexible development experience and more extensible architecture as discussed below when using derived classes and things...etc but we can live without it as there are ways around as detailed below... it certainly would make life easier.... to have them split into seperate files...

For internal Script generation i think you are ok with it as it is...

1. i am saying using seperate dlls instead of 1 monolithic dll is far better architecture and
and allows extensible development with strategies and derived strategies having equal context view of indicators and the wrappers to instantiate them....
2. removes the need to ship around loose open source .cs files with compiled files to
3 it also removes issues when loading indicators into memory onto a chart - when adding from basclasses and derived classes.... there is a myriad of things to go wrong there - resolved by partial classes and overriding the methods in the base class to execute and load the indicator at the derived class scope...
4. stops messages about AV

if you are a developer of this end stuff you will understand why as a developer on NT you wont have the same view ofcourse not ... i can send in a pattern that shows the problem with your 1 file and how it is resolve and.. if you are interested

Most certainly with seperate dlls you would really have something special as it is its not your full potential with 1 file - you should really always use seperate dlls... for strategy,indicators and other objects and you will unleash some very powerful stuff - keep it one dll and you are limiting the usage of it... somewhat and making things complex for the end developer who wants to release compiled base classes for people to use as base classes for their strategies...

i cannot see that you have experience this with your reply - i will if time do a video and show the issues with the architecture of 1 custom.dll and the ns wrappers - i think for you end its not a big issue at all.. and if you want the very best for your product its time to forget the history of what was decided and take a fresk look at the present and make a change and have the best you can while you still got time to make the change and resources....to focus on it

[MicroTrends]

S
Also:
- splitting up the NinjaTrader.Custom project in separate assemblies makes no sense. We discussed that internally several times already.

what criteria was used to make the judgement? please provide the reasons...

Even if you dont like my reasons which are fact from the end client perspective

Removing the horrendous issues with importing and compiling things in NT7 looking at the support time and cost and distraught 1000s of traders who hate that process - is that not 1 good reason?

Lesson: Developers should not design and control product evolution....
End users and requirements should

S
we discussed that internally several times already.

So now with NT8 still in BETA... surely anyone with an open mind would agree - it would be good to discuss this externally too and use the feedback of people who use your product and have information and evidence to the contrary and want the best for your product for the benefit of all


Conclusion
Blatantly it does make sense to use side by side dlls if you follow the thread and look at the evidence that can be presented to you if you are open to improving - you were open to making NT8 better than NT7 with newer technology so surely you will want to improve this area too?


As a very capable developer that you must be i find it puzzling that you dont see side by side assemblies as much better for development than a monolithic dll.... i believe it is because you are extremely busy and focused on other areas - its ok.. .we are on the same team

i will prepare my case fully and provide all evidence in a seperate thread -


but thinking about it i don't much have time and i have a solution i was thinking of the other developers... the key to this is if you can remove the loose .CS file you ship with compiled DLLS then it is worth doing etc..... if compiled and derived classes have access to the same NS Wrapper Methods.... and calls to addIndicator( dont cause exceptions)
if using side by side dlls removed all by splitting it out into seperate dlls - then yes change it...]

i will attempt to do this and post it sometime soon

[NinjaTrader_Dierk]

2 different issues which are not related:

A) (as per original poster) how to handle the wrapper code?
- there is no way around wrapper code for reasons discussed below
- there is no point is separating out wrapper code to a separate file as this could cause confusion e.g. people manually copy around the NS file but 'forget' to copy the wrapper code file as well

B) splitting up NinjaTrader.Custom.dll
- there is no gain for >95% of the users
- the experienced/power users always could separate our their customized NS files into separate assemblies. Partners needed to export their custom product to a separate assembly anyway

Please don't forget:
- the objective of the beta phase is to fix issues/bugs which would get into the way of >95% of our users. The objective of the beta phase is *not* re-designing core parts of NT8 and changing and exposing to risk what has worked great the past few years
- the solutions we chose are to address the needs of >99% of our users which they do and did in the past (NT7 and earlier). Power users might have different requirements but they usually have ways to work around limitations

[NinjaTrader_Dierk]

On your suggestions related to this exact topic which you posted in a separate thread

http://www.ninjatrader.com/support/forum/showthread.php?p=410554#post410554

In case you are not aware: the wrappers needed to be generated not only for indicators but for strategies and MA columns as well. The simple reason is that the wrappers are used in strategies and MA columns too.

So in indicator, strategy and MA columns code you should be able to write identical code like this:

double value = SMA(14)[0];

[MicroTrends]

On your suggestions related to this exact topic which you posted in a separate thread

http://www.ninjatrader.com/support/forum/showthread.php?p=410554#post410554

In case you are not aware: the wrappers needed to be generated not only for indicators but for strategies and MA columns as well. The simple reason is that the wrappers are used in strategies and MA columns too.

So in indicator, strategy and MA columns code you should be able to write identical code like this:

double value = SMA(14)[0];

yes i can see that in the code sure.... i wondered if a static implementation would negate the need for that - but really its only a wrap - maybe a virtual or static would gain ground - and negate the need to duplicate and send out the loose cs file....

so i guess my real question is
why the lose cs file with compiled dll
Exceptions on adding
and would seperate dlls help that etc//

and i provided a pattern that allows you to get around it all in the thread and will use it for NT8....

I also appreciate it would cause a lot of work perhaps for as you say 95% of people no gain.... thank you for you time i respect your knowledge a great deal

[NinjaTrader_Dierk]

>> static implementation
... won't do it. Please see e.g. this

namespace NinjaTrader.NinjaScript.Strategies
{
	public partial class Strategy : NinjaTrader.Gui.NinjaScript.StrategyRenderBase
	{
		public Indicators.ADX ADX(int period)
		{
			return indicator.ADX(Input, period);
		}
...
	}
}

.. in ADX implementation where 'indicator' needed to be an instance variable. Just debug through the code of e.g. 'ADX(14)[0]' to see what's going on and why this needed to be instance methods and can't be static

[gregid]

MicroTrends has made some valid points but coming backt to my original post.
At the moment every time you edit indicator in Visual Studio and click save - it executes compile and you receive pop up in Visual Studio requesting reload of the indicator you just saved since it has been changed externally.
My thinking is as follows (correct me if I am wrong) - if this code is generated by NinjaTrader every time the compile is executed then this code (partial classes) may be as well placed in some 1 file common for all Indicators/Strategies/MarketAnalyzerColumns - this could even be a dll. I understand the need for this code to be generated - I just don't understand the need for this code to be in the same file (and causing constant reload requests in VS)

[NinjaTrader_Dierk]

>> it executes compile and you receive pop up in Visual Studio
The reload is triggered by re-generating the wrappers which is independent of compiling.

>> I just don't understand the need for this code to be in the same file
For reason stated below: 2 files would be causing more potential sources of trouble as people 'forget' to copy the file which holds the wrapper in case they manually copied the indicator file.

The solution to that problem would be re-generating wrappers only as something has changed which I added as suggestion #339 to the list.

[MicroTrends]

>> static implementation
... won't do it. Please see e.g. this

namespace NinjaTrader.NinjaScript.Strategies
{
	public partial class Strategy : NinjaTrader.Gui.NinjaScript.StrategyRenderBase
	{
		public Indicators.ADX ADX(int period)
		{
			return indicator.ADX(Input, period);
		}
...
	}
}

.. in ADX implementation where 'indicator' needed to be an instance variable. Just debug through the code of e.g. 'ADX(14)[0]' to see what's going on and why this needed to be instance methods and can't be static

yes.. when i sent that.i guessed so a lot of reworking and things - the other methods would about locals and things etc

Its hard without the codebase of NT to play with :-)

As an add on i might look at something generic for fun....
one idea is a IndicatorFactoryHelper Class....
that could have static methods and return a type of the indicator passed to it with the parameters

namespace NT.Indicator
IndicatorFactory.CreateAndStart(string className, bool addToCache)
IndicatorFactory.CreateAndStart( Indicator indicator , bool addToCache)
IndicatorFactory.CreateAndStart(Indicator indicator, objects[] params, bool addToCache)
IndicatorFactory.CreateAndStart( type indicator, objects[] params, bool addToCache)

also at partial class indicatorBase level static or not..

IndicatorBase CreateAndStart().... various overloads

at an indicator level Static perhaps or for instance...
EMA.CreateAndStart(input)
EMA.CreateAndStart(input,params)

But agreed it is what it is - and least path of resistance is to keep it as it is
and there are patterns that get around any caveats with the old NT7 behaviour i look forward to tinkering more with NT8....

thanks for your input