A True developer's library (API) file(s)

[Obi]

Hello,

I don't know about the rest of the NT community (maybe it's just my inexperience), but I have failed to do the following simple steps with NT6.5 on all occasions:

1. I have NT6.5 Script and its API, exposed (made available) in one (or several) of its lib files
2. The API is primarily exposed in C# (or any of the .Net stuff)

Now,

Q1. Ideally, one would need one or few clear "lib" files (.dll, .so, etc.) that will clearly
provide an 'Interface' (definition and usage) for Strategies and Indicators development.

What I mean here, is 'include' (import, 'Using' in this case) one or few specific lib files
will give me access to 'Indicators' and 'Strategies' "public" methods.

Specifically:

Within my C# dev env (MS Vis. Studio, etc.), I include say NT7A.dll and NT7B.dll, then
I can call/use 'Indicators' methods and 'Strategies' methods and stuff.

I say 'stuff', because it can be:

a. Strategies methods such as: HighestBar, CrossAbove, etc.
b. Price bars, Position data, IOrder objects, etc.
c. 'Properties': CalculationMode, etc.
d. And more.

Now many will argue that it can currently be done. I'm sure it can, but not without any 'deep' knowledge of these 'lib files' and probably some sort of tweaking. Not in the 'straight form' of:

- Include, compile and run.

What I am talking about is a well published and 'for the purpose' built libraries:

'Include' in your C# code

- For strategies methods and properties: NT7A.dll
- For Indicator methods and properties: NT7B.dll


Q2. Existing 'lib files' are overlapping, meaning some API methods can partly be found in
one lib file and some others in other lib files. and 'including' both 'lib files' causes NT6.5
to throw an exception at run-time that some of the 'lib files' or methods were already
included.


In these issues, even if it is my understanding on the usage of these 'libraries' that is skewed, it highlights the need for a clean, clear libraries designation for developer who would venture to capitalize on the advantage provided by the C# programming language.

If forcing people to use just the NT6 (or 7) environment for any strategy development, that will remove any advantage of using such a high-level prog language and you might as well use any kind of toy scripting language for that matter.

Obi

[MicroTrends]

I would argue this a true developers platform.

It is only limited by experience.

Please see attached image.


I think the trouble is that a bit like when microsoft allowed people to use access - you had a load of people claiming to be database experts over night because they can create a a table in access- NinjaTrader have opened the door to that kind of trouble with the scripting utility....but they have allowed many people to create useful tools in the process and access to seasoned professionals and partners to assist...

It would not be as extensible if all the code were placed in one old style monolithic dll - as you know this approach went away in 1995 - large assemblies were replaced and seperated out into link libraries with the advent of WOSA and re-entrant multitasking process - vs non re-entrant dos based process.

Today we can do even better - not that its new - we can late bind and load via interfaces, strongly typed assemblies...compiled up front and loaded and invoked at runtime where as in around 1999 you could late bind - but fail at runtime

Today we must have a framework created, to allow different teams to work in parrallel to a schedule under mutating requirments, so projects are arranged and worked on in a modular extensible way - it is not good to lock one bit of code for modificaiton if it locks the whole project team out from working in parrallel... We need to also hire other programmers and maintain what we have done from the past...we need structure..

Then you have the modern event model programming, object model approach, requiring namespaces, class names all compiled as seperate files with good anming for maintenance -

i think NinjaTrader need an award for they achieved - I have worked on many multi million pound systems quite frequently as an architect and developer and can tell you that what they have achieved is very rare. I have seen banks throw millions on R&D down the pan year after year and screw up and thorow more money at it... and not achieve what NinjaTrader has..

There are some limitations - but this is because of structure and interfaces- NinjaTrader is also partly a "smart client" which means you can dynamically add in external libraries supporting specific interfaces, indicator, strategy, market analyzer... without having to rebuild and redistribute the whole application again... These custom assemblies are then imported into a registry, compiled into NinjATrader it seems and perhaps loaded on request via reflection and invoked... they are part loaded on startup so later on can be invoked and shown on a chart etc...

It seems that there is a need to force consistency generate the constructors - thats fair enought it works well - but in distrubuting and recompiling i would argue is not the best route when mature published patterns exist for dealing with this in windows applications.

SMART CLIENT
PROVIDER MODEL

My only gripe is that for some reason the NinjaTrader pseudoe smart client implementation requires cs files to be compiled in on import so it seems. there is no need for that if you simply load and invoke an assembly which supports the correct base interface you need for a chart to laod an indicator - that part causes issues with duplicate methods and all sorts and can be annoying.

I would argue this can be achieved a lot easier in a few lines of code using reflfection and invocation - the calling smart component would deal with all the stuff that the constructor does ...but each to their own...it is what it is.

Also i would use the provider model pattern for the data adapters if not done so already... loose bound dlls not compiled by reference...
This could have also been utilised for the DAL for access, sql, etc
ASP.NET made this a commerical success and it is available as a library.

The whole applicaiton should be database agnostic - so we neednt be restricted to an embedded database - we could just choose the data provider - the DAL should seperate out that part via the use of adpaters.
so the BLL only needs one DAL interface.

Afterall transactional databases like ms sql are out of the ancient 1980s - a tick database is far better for trading applications - but 50K per cpu is expensive...and dont handle multi concurrency read writing, SQL or many other advantages with MS SQL... storing data in the file system and using mssql ce is a good thing to do - but i have an itanium server and MS SQL SERVER 2008 on it i could be using.....and a tick database...

A great thing to do would be to have a smart client approach for the presentaion layer, expose a BLL and DAL, and the widgets, indicatrs, strategies. We could then create windows applications which run in their own right and can be dynacamically invokled at runtime in the Shell. They would be sub classed and dispalyed as a mdi child or within a tab...

I would like to see proper usage of application config files.

But I am a nerd and have been programming since the age of 10 and that was even assemby and basic on amstrads, siinclairs, BBC Micros - nearly 28 years ago now holy moly... i would actually work for NinjaTrade if i wasnt based in europe and trade too...

perhaps then that is why they they have to protect a lot from plageurism and have to continue with a legacy framework. It is still a fantastic job though. First class.

The script utility they have provided gives you all you need to program with- it means you dont have to fork out on Visaul Studio or even be any good at programming.

To do what i think you want - all you need to do is explore the NinjaTrader class library and that is very easily done for those coming from a commercial programming background.

You can see all of the classes you need if you use Visual Studio - You just have to know how to do it. You can use a class view or the object browser. Just add the appropiate references and all is revealed...

Ninjatrader uses the c# compiler so does VS - so you can do anything you want in theory and compile from VS2005.

There is a way of simply passing a reference or context of the strategy out to an external class- and so you can program very structured 3rd part dlls and then distribute them with a setup program

3.5 will expand the c# capability with class extensions...


I have hit walls head on programming - but i have always found a way around it - that is the nature of any commercial programs i have ever used though :-) Nothing is ever easy..


Hats off to NinjaTrader...

[koganam]

You have not by any chance determined the command that NinjaTrader is using to run the csc to compile, have you? I have tried multiple methods, but the csc still complains that it cannot find a lot of the standard NinjaTrader attributes.

I need to compile from the command line when I distribute custom indicators, just like NinjaTrader does when one imports an indicator from the GUI. Otherwise, telling customers to shutdown and restart NinjaTrader before they can use the indicator just looks hooey.

[MicroTrends]

I haven't acutally thought of tracking it down, I guess you could send a button click to compile or hook into the message queue or find the method with reflection etc


Looking at it from another perspective, perhaps all you got to do is start the CS compiler and send the appropiate commands in...

"but the csc still complains that it cannot find a lot of the standard NinjaTrader attributes."

Is there a log or trace/ stack inspection/ message queue hook, that can provide the arguments sent...to CSC? is it just a case of the working folder?


I do have a setup program for my indicators/strats, It's a 2 step approach deploy and install dependencies, then import into NT... people do get confused... I also have a an updater running, but it cannot simply update the dlls... The issue is custom.dll needs building, As you say if an official command line compile was provided as a post install step for installers, that would be great !

please let me know if you find out!