NinjaScript generated code

[gregid]

The reload is triggered by re-generating the wrappers which is independent of compiling.

Thanks

>> 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.

My impression has been that if I paste content of the indicator without wrapper part - it generates the wrapper automatically - so if it generates it automatically what is the point of including the wrapper in the exported NinjaScript. I was thinking about each NinjaTrader installation having local cs or dll file containing all the wrappers for cs files in the Custom projects (wrappers being locally generated and not transferred at all).

To recap: If every NinjaTrader can and does generate these wrappers - what is the point of transferring the wrappers between different installations?

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

Thank you, I am fine with every solution that streamlines the NT - VS integration

[NinjaTrader_Dierk]

I'm not sure if we're on the same page on how the wrappers and the NS export works:
- NS indicators wrappers are needed for reasons I explained below: that you could consistently access/use indicators in other indicators, strategies or MA columns like this

double value = SMA(14)[0];

- if you as a NT partner exported your custom NS indicator 'MyCustomIndicator' then several things happen:
* an assembly is compiled (if you chose so)
* NT generates a CS holding the wrapper code which your customer will need if they wanted to use your indicator in their indicator/strategy/MA column like this

double value = MyCustomIndicator(...)[0];

There is no need for you to paste anything.

What's wrong with that?

[koganam]

I'm not sure if we're on the same page on how the wrappers and the NS export works:
- NS indicators wrappers are needed for reasons I explained below: that you could consistently access/use indicators in other indicators, strategies or MA columns like this

double value = SMA(14)[0];

- if you as a NT partner exported your custom NS indicator 'MyCustomIndicator' then several things happen:
* an assembly is compiled (if you chose so)
* NT generates a CS holding the wrapper code which your customer will need if they wanted to use your indicator in their indicator/strategy/MA column like this

double value = MyCustomIndicator(...)[0];

There is no need for you to paste anything.

What's wrong with that?

If I may weigh in, as all responses seem to be on the other side, I think that your current paradigm, is the correct one, especially because of concerns regarding code distribution. Let me explain.

The current method neatly steps around the issue of synchronizing the source and the wrappers, if and when the code is distributed. If distributed as an assembly, the wrappers and code are broken out, but placed in the same zip package, which as it is always distributed and imported as a package ensures that the wrapper file and the code file are always together. On the other hand, if the code .cs file is distributed in open format, all the wrappers are ensconced in the same file, again ensuring that the wrappers get distributed with the class code.

If you break out the wrappers from the class code, we immediately run into file naming issues, and distribution clashes as, for example, have happened pre-NT8, where you provided UserDefinedMethods.cs as a file, for self-evident use, but warned that because of overwriting concerns, the file should never be distributed. We all know that many folks, instead of using UserDefinedMethods.cs as a template to create their own partial class files, instead just distributed the UserDefinedMethods.cs file anyways and created the kind of issue that caused NinjaTrader_Matthew to respond in this manner in this somewhat related thread: http://www.ninjatrader.com/support/f...ods#post410370

Breaking the wrappers out per file is neat programmatically. Unfortunately the reality is that even the best of us will sooner or later distribute the class cs file and forget to also distribute the corresponding wrapper file. Even if we did not, inevitably there will be distributors who each have named their files identically, and then we have the same issue that occurs today from such a filename clash, but now exacerbated to also requiring that the wrapper files must also be correctly paired to their relevant class file ( - quadruple the trouble, manually syncing 2 files to 2 other files, as it is to have to determine what to do when only 2 (complete) cs filenames clash.

[gregid]

Pasting was just an example (of indicator with no wrapper) - completely irrelevant to the point I was making.

Thinking about wrappers I didn't take into consideration compiled assemblies. My suggestion (of locally generating wrappers) would only work for uncompiled cs files.

So, there is nothing wrong with the existing solution - just doesn't make much sense if one thinks of only uncompiled cs files for which NT generates the wrappers anyway (and that's what I did).

EDIT: Anyway - my main point was really to cut the need of reloading files in the VS - so whatever works here I am happy.

[NinjaTrader_Dierk]

>> just doesn't make much sense if one thinks of only uncompiled cs files for which NT generates the wrappers anyway

Incorrect.

There are 3 cases, in all of them the wrapper code is needed:
a) export compiled assembly -> wrapper code is needed as per conversation below
b) export source NS -> wrapper code is in source file and needed
c) no export at all -> wrapper code is needed

For all 3 cases the wrapper code is needed to do something like this consistently in indicators/strategies/MA columns:

double value = SMA(14)[0];

[gregid]

Where did I say wrapper is not needed? I only initially suggested they could be locally generated - that's it. No reason to fight with something I've never said.

[MicroTrends]

Yes all agreed: NS Wrappers generated are vital to save a developer the time...
to write code that starts them and allows them to be added to a chart or use nice inline syntax in other objects columns/strategies etc...


Due to the current architecture i cannot see an alternative - i guess i was saying given time and the ability to refactor it would be great to remove the need to ship NSWrappers... and the advantages to break things into seperate dlls to assisst with some behaviours - when deriving a strategy from a compiled dll ( which has wrappers and indicators compiled into its scope/context)

All of which are resolved in the pattern here in Post 1

http://www.ninjatrader.com/support/forum/showthread.php?t=74006

Workaround and code provided there to show how to get around the issues - i updated it

To get around the issue of:
1. how to make indicator wrappers visible to classes compiled later derived from compiled classes - and which instance of indicator - to use..
2. avoid exceptions (cross threaded errors?) when adding to a chart via a strategy - when an indicator is compiled into 2 different locations for example - 1 base class and 1 derived class and added to a chart... Boom! unless you defer the call and override to the derived class...

The question really revolved around NSWrappers are 100% neccessary to be scripted into the indicator... if given the choice to investigate and refactor the code base etc...
i.e. why ship around the nswrappers in open source surely there was an alternative etc... Suggestions of replacing the 1 custom dll to hold the indicators referenced by all others- not to have them in a monolithic dll etc...

indicators are compiled into the same dll for a strategy... so in fact duplicated...
and then maybe duplicated again in derived dlls... so the same class lives in multiple dlss of type indicatorbase but is not the same.... it can only really be the same if it lives in 1 dll... called by others

So as you know then an indicator won't live compiled in multiple dlls but in one which is a basic extensible programming pattern - allowing access to the same object from many places etc.. so remove the #2 issue ie. so the location of the indicator created on the chart would be from the same location for example when using scenarios explained... ie from 1 dll.

in short it is what it is currently - and the workarounds i use for me and provided in the other thread: allow it to work with some extra snippets in open source and its ok as it is but i would sure be looking to move away from that if i were given the chance to write an update for NT :-)

Mainly due to all the troubles it causes for so many when importing and all the errors and downtime etc...

For the NT Errors: we probably explain to people all the different scenarios here:

https://microtrends.zendesk.com/forums/21166289-Installation-and-troubleshooting

https://microtrends.zendesk.com/entries/20298978-custom-NinjaScript-Files-on-your-PC-that-have-programming-errors

In truth there were with NT7 10000s of cases of problems and lost hours per year amounting to a huge bottleneck and annoyance for all involved...when importing..etc..

So having a way to access the methods scripted and compiled into the indicator would be best - accessible from indicatorbase - but i guess that's a huge amount of reworking etc....

maybe class extensions could work better.... with some other refactoring etc...
I am ok with the architecture and understand it's ok and not a priority to change etc even if the case was more easily explained :-)

[MicroTrends]

Where did I say wrapper is not needed? I only initially suggested they could be locally generated - that's it. No reason to fight with something I've never said.

probably my fault for hijacking the thread very sorry about that i muddied the water!
locally would be a great idea... have the methods to do the generated in one place in one dll instead of many compiled version of it in many places... and dlls...

i wonder if class extensions could help in someway...

maybe one other benefit of seperate DLL is if the indicators were generated seperately in a dll reflection could be used to script the code - then other strategies with incorrect signatures would not prevent compiling...aslo loading of the indicators and properties using reflection...btw.... then bringing into scope parameters inherited in indicator base classes that are derived from in other custom indicators.... which the macro reading the script cannot see - as it doesnt follow the class hierarchy - relfection would load the end result and iterate all properties as you would expect...of category "NTparameter"

Also then a partial nswrapper file could be generated once... the NSWrapper does not have to be updated unless the public parameters change in the indicator - getting around VS file change messages...

SEALED workaround to stop the script being generated

FWIW: You can stop the NSWrapper being re scripted on a compile by setting the indicator class to SEALED....

public sealed class EMA2 : indicator
{
}

This might have an impact on the usage of the indicator in a strategy.. later...as a dll you would have to create that part yourself to make it visible... eg the loose wrapper file etc - or when you are 100% done set the indicator to:

public class EMA2 : indicator
{
}

to get all the wrappers generated again - you would need to edit and compile the indicator directly for the editor to script this btw...

[NinjaTrader_Dierk]

@MicroTrends

a) >> great to remove the need to ship NSWrappers
Based on all my explanations below: are we in agreement that this is simple not possible if you wanted to code something like this

double value = SMA(14)[0];

- if yes, then I suggest we closed off that issue
- if no, in which of the cases a - c in my post #20 below don't you see a need for wrappers

b) >> the NSWrapper does not have to be updated unless the public parameters change in the indicator
Are we in agreement that as per my post #14 this already is on the list of suggestion as item #399?

c) >> as a dll you would have to create that part yourself to make it visible
Are we agreement that this is not what we can do since >95% of our users needed exactly that: pre-generated wrappers for consistent use in indicators/strategies/MA columns?

[NinjaTrader_Dierk]

Where did I say wrapper is not needed? I only initially suggested they could be locally generated - that's it. No reason to fight with something I've never said.

This would be asking for trouble for > 80% of our partners: "why could my customer do this with my indicator 'MyCustomIndicatorA', but I can't do it as I wanted to use my own indicator 'MyCustomIndicatorA' in my indicator 'MyCustomIndicatorB' like this":

double value = MyCustomIndicatorA(...)[0];

[MicroTrends]

@MicroTrends

a) >> great to remove the need to ship NSWrappers
Based on all my explanations below: are we in agreement that this is simple not possible if you wanted to code something like this

double value = SMA(14)[0];

- if yes, then I suggest we closed off that issue
- if no, in which of the cases a - c in my post #20 below don't you see a need for wrappers

b) >> the NSWrapper does not have to be updated unless the public parameters change in the indicator
Are we in agreement that as per my post #14 this already is on the list of suggestion as item #399?

c) >> as a dll you would have to create that part yourself to make it visible
Are we agreement that this is not what we can do since >95% of our users needed exactly that: pre-generated wrappers for consistent use in indicators/strategies/MA columns?

Yes always agreed... no one said that we wanted to remove the ability to write that syntax -provided by the NS Wrappers... just that its not the best thing to have kept from NT7... as the are a small myriad of problems around that area... Yes in your current implementation it's the only route - unless developers provide another layer and methodology to expose those methods..

This is due to the fact the legcay NT7 pattern was migrated to NT8 ... not the best for reasons cited but i understand very hard to change... and i still commend the pattern as an achievement -it's only with usage overtime we can see where it could have been changed and bettered for the NT8 rewrite - but it is migrated already- so the legacy stands.

Summary:
The Current implementation is not the only way... but agreed to change to another would require significant refactoring of the code base.... i also pointed out other reasons as to why seperate dlls are the better pattern... for multiple reasons such as class hierarchy and using easier techniques to script the nswrappers including inherited properties and avoid issues with charting and strategy/indicator adding in derived strategies -and exceptions when adding indicators compiled into different dlls.... and base classes etc ie where the add was called from and where the indicators live etc

A. Importing - It's an Achilles heal the way it works now, causes horrendous issues with many users... who need assistance to simply import an indicator due to errors...

B.In NT8 you are not providing a better development and deployment experience in that particular area that would appeal to new market audiences for your platform such as commercials who can bring volume.... -but for 95% of the current user base its ok as it is apart from .A..is not the best...

C. in all other areas you are excelling.... :-)



NT7 was limited and so will be NT8 to that scenario - as it uses the same patterns for that... NSWrappers thing.... and limited on the usage of compiled foundations.... but its ok there was a solution... i also provided patterns that get around the limitations of the archticteture when using compiled base classes and derived class -

http://www.ninjatrader.com/support/forum/showpost.php?p=410547&postcount=1

Conclusion
If you have 2 versions of NT - and were lucky enough to have the time and resources and budget to do this:
1. one with the legacy version of NT7 import export of files in NT8
2. a Version of NT8 one with a new way without all the open source paraphernalia and NS Wrappers distribution

#2 would be the winner with the more commercial users 100% as you could at ease code in with best practices for .net and side by side assemblies etc Also retail hobbyists would use it- due to the reliability issues of #1 - 10000000s of hours across the user base are wasted with your current implementation you underestimate how horrendous traders with no idea how to fix compile errors find it.

Time to focus on stuff that is more important thanks for you input....

Maybe i can get a copy of the NT8 code base and try write pattern #2 for you:-)
that would be a dream -

final conclusion i love NT you are doing great regardless of my rants - i understand some of what I ask is not 100% essential and very hard to change ;-)

[NinjaTrader_Dierk]

Thanks for clarification.

At this time we have no resources and nor the intent to implement a '2nd version of NS not using wrappers' to meet the requirements of < 1% of our users. Those who are interested pursuing this path could replicate as needed what the wrappers do and work around.

[MicroTrends]

Thanks for clarification.

At this time we have no resources and nor the intent to implement a '2nd version of NS not using wrappers' to meet the requirements of < 1% of our users. Those who are interested pursuing this path could replicate as needed what the wrappers do and work around.

Perfectly understood sir :-) a custom installer would be used then etc

But you would please perhaps 99 % of your users if you got rid of the the perhaps 2nd worst thing about NT.... maybe you should have done a survey...

1.NT7 - charts dont load -FIXED 1000% - PRIORITY Critical
2.NT7 - Importing... problems - - PRIORITY - low? medium -- umm well it is what it is - lets see how it goes in NT8... :-) Just imagine 1000s users per year with compile issues... and the wasted time....some of them stuck for days and weeks.... that's not the best light to paint your skills with....

Dont forget now that NT8 is proving to be a viable trading platform - so commercial funds, and imagine prop shops and screen trading firms using NT8 instead of CQG and TT??? Thinking ahead for the future - ironing out these issues in NT7 from migrating to NT8 perhaps was a window of opportunity... but agreed #2 was the last thing to change :-)


Maybe NT9 - Post WPF WinrRt/ Cross HTML5 tablet mobile phone pc edition will have a downloads app store :-) but please resolve it then in about 5 to 10 years :-)

[NinjaTrader_Dierk]

We are open to revisit the issue as there is sufficient demand down the road.

[MicroTrends]

We are open to revisit the issue as there is sufficient demand down the road.

Now that is a win win Idea... if you were to implement desktop anayltics to measure bottlenecks and remote automatic exception tracking then you would not be guessing about this ( nor would i) . We used to get a lot of reports but i can tell you now we use installers less than 1% all issues in our help desk is...
"I tried to import and it says i cant blah blah blah......" hence i wrote out many of the scenarios and provided the fixes... and in google analytics this is one of the busiest areas :-)
e.g. https://microtrends.zendesk.com/entr...ramming-errors

So yes model something on Telerik exception tracking and see the demand in realtime your end as to what the real % ...so the users don't have to report it first..... as the truth is many think "someone else can report that i give up with this darn stuff....."

We are on the same team - thank you for your time and patience with this...