Indicator: Order of parameters (in NT generated code)

[misova]

I would like to report a problem+ suggestion for improvement:

Problem:
When compiling indicator, NT generates custom code for getting (cached instances) the indicator, that are then used in all other code.

Problem is, that generated parameters (Properties of the indicator) have alphabetical
order, which causes an extreme chaos of all mixed Properties.

I expect, that I could name all properties alphabetically, but this is really not a solution,
just ugly hack. I would not prefer to use any prefix like A01_MyProperty, B02_AnotherProperty, because it is really ugly (even if that works).

SUGGESTION
There should be an acceptable rational solution like adding metadata for order
of generated parameters.

Just do it the same way like it is done with [Description], [DisplayName] and other metadatas already present.

It is also needed, to be able create professional indicators with logical and nice order of parameters, instead of chaotic and mixed order generated by the alphabetical sorting implemented now.

[NinjaTrader_CalH]

Hello Misova,

Thank you for your note.

I will forward your suggestion to Development to look into and consider for NinjaTrader 8


Let me know if I can be of further assistance.

[misova]

Thankx,
just adding an example how ugly order of parameters make all the input completely chaotic.
In reality, there are 4 very logical groups of related parameters.
If they could be ordered explicitly, the interface for using any indicator would be much more user friendly.

This alphabetical looks for each user of the indicator chaotic:
Ideal and rational order of parameters would be completely different.
First things are not first, and parameters with least importance are first.

[FONT="Courier New"][SIZE="2"]public EmaTrendStateIndicator EmaTrendStateIndicator(
Data.IDataSeries input, 
int consolidationStart_AllEmasRange_InTicks, 
int consolidationStart_BarBodyInsideBollingerBands_Period, 
int consolidationStart_BarBodyInsideBollingerBands_StdDev, 
int fullTrend_DistanceBetween_MainEmaVsEma200_MinInTicks, 
int fullTrend_DistanceBetween_PriceVsEma200_MinInTicks, 
int fullTrend_MainEma_KeepSlope_LookbackInBars, 
int fullTrend_MainEma_Period, bool shouldColorizeBars, 
bool shouldDrawLine_InitialMoveOfMA, 
bool shouldDrawLine_InitialPriceMove, 
bool test_Enabled, 
string test_Filename_InsideNtFolder, 
bool transitionFromWeakenedTrendToFulltrend_ByBreakingExtremeOnly_Enabled, 
int transitionFromWeakenedTrendToFulltrend_MinBreakOfFulltrend_InTicks, 
int weakenedTrend_FastEma_Period, 
int weakenedTrend_SlowEma_Period)[/SIZE][/FONT]

It is common, that more sophisticated indicator have many adjustable settings.
But final chaos of parameters is something, you would never like to see as a programmer.

The order & name of the parameters should be explicitly adjustable to achieve clear and nice API.

(We can reorder them manually, but with each compilation, they are rewritten to default names & alphabetical order, so this is not the way to go.)

[koganam]

Thankx,
just adding an example how ugly order of parameters make all the input completely chaotic.
In reality, there are 4 very logical groups of related parameters.
If they could be ordered explicitly, the interface for using any indicator would be much more user friendly.

This alphabetical looks for each user of the indicator chaotic:
Ideal and rational order of parameters would be completely different.
First things are not first, and parameters with least importance are first.

[FONT="Courier New"][SIZE="2"]public EmaTrendStateIndicator EmaTrendStateIndicator(
Data.IDataSeries input, 
int consolidationStart_AllEmasRange_InTicks, 
int consolidationStart_BarBodyInsideBollingerBands_Period, 
int consolidationStart_BarBodyInsideBollingerBands_StdDev, 
int fullTrend_DistanceBetween_MainEmaVsEma200_MinInTicks, 
int fullTrend_DistanceBetween_PriceVsEma200_MinInTicks, 
int fullTrend_MainEma_KeepSlope_LookbackInBars, 
int fullTrend_MainEma_Period, bool shouldColorizeBars, 
bool shouldDrawLine_InitialMoveOfMA, 
bool shouldDrawLine_InitialPriceMove, 
bool test_Enabled, 
string test_Filename_InsideNtFolder, 
bool transitionFromWeakenedTrendToFulltrend_ByBreakingExtremeOnly_Enabled, 
int transitionFromWeakenedTrendToFulltrend_MinBreakOfFulltrend_InTicks, 
int weakenedTrend_FastEma_Period, 
int weakenedTrend_SlowEma_Period)[/SIZE][/FONT]

It is common, that more sophisticated indicator have many adjustable settings.
But final chaos of parameters is something, you would never like to see as a programmer.

The order & name of the parameters should be explicitly adjustable to achieve clear and nice API.

(We can reorder them manually, but with each compilation, they are rewritten to default names & alphabetical order, so this is not the way to go.)

You can always write your own instance constructor, with parameters ordered in the manner that you prefer.

[NinjaTrader_PatrickH]

Hello misova,

Thank you for your response.

You can order the parameters by passing \t to the string in DisplayName, for example: [Gui.Design.DisplayName ("\t\t\tQuantity 1")]

This is used in the SpreadCandlesticks indicator at the following link: http://www.ninjatrader.com/support/f...d=4&linkid=512

[ninZa]

My simple solution (used in all of my indicators) is to number them by group: 1a, 1b, 1c, 2a, 2b, 2c... No headache for this.

[Gui.Design.DisplayName ("1a. Quantity 1A")]
....

[Gui.Design.DisplayName ("1b. Quantity 1B")]
....

[Gui.Design.DisplayName ("2. Quantity 2")]
....

[misova]

Thanx,
I also use this type of sorting in GUI Properties. That is OK.

The Problem is programmatical use of the indicators...
The generated code causes ugly alphabetical order of parameters, without any logical order.
Using indicators with unintuitive and mixed order of parameters is pain and causes ugly code.

Indicators should have logical and meaningful order of parameters, so they can be easily
used when developing trading strategies..

[koganam]

Thanx,
I also use this type of sorting in GUI Properties. That is OK.

The Problem is programmatical use of the indicators...
The generated code causes ugly alphabetical order of parameters, without any logical order.
Using indicators with unintuitive and mixed order of parameters is pain and causes ugly code.

Indicators should have logical and meaningful order of parameters, so they can be easily
used when developing trading strategies..

Again. It is just C#. Write your own instance constructor, ordered how you want the parameters to be ordered.

[ninZa]

Again. It is just C#. Write your own instance constructor, ordered how you want the parameters to be ordered.

Is it complicated Koganam? Can you give some sample codes that you use?

I'm also interested in this subject.

Thanks.
Pi