Force the order of the parameters in an indicator

[sbgtrading]

Right now, the parameters are sorted alphabetically when you "Ctrl-I" on a chart. How do you change/override the order of the list in the NinjaScript code?

[NinjaTrader_JoshP]

Correct the list will be organized alphabetically. If you wish to work around this you can try adding numbers in front of your parameter names?

[OnePutt]

I asked for the option to not sort the parameters alphabetically nearly a year ago while NT 6.0 was in Beta. Apparently this simple and logical requirement is not high on the priority list. With strategies that have a lot on inputs this would make it much easier to quickly review the important or more likely changed parameters without scrolling up and down.

Maybe if more people express an interest...................

[zoltran]

Ok, I'm interested too...

(but I doubt it's simple OnePutt .. My guess it's a .Net default that's hard to override)

[NinjaTrader_Dierk]

Here's a hint from the "magic and mystery" box (neither tested nor officially supported, you would need to play with it): try adding
[DisplayName("\tMyPropertyName")]

Idea:
- \t should not be displayed
- cascading \t would allow you to sort

[sbgtrading]

I'm not sure I understand what you're suggesting. The "MyPropertyName" is the string that it would then sort alphabetically instead of the variable name? Do you have an example to post?

Here's a hint from the "magic and mystery" box (neither tested nor officially supported, you would need to play with it): try adding
[DisplayName("\tMyPropertyName")]

Idea:
- \t should not be displayed
- cascading \t would allow you to sort

[NinjaTrader_Dierk]

Sorry, I just tried to provide a hint to the programming savy people (who are familiar with the idea below and the DisplayName concept). If that does not sound familiar: please scratch my hint below since this is a non-supported concept.

[KBJ]

Just as a test, I did a save-as on the MACD indicator and changed the parameters so they'd display in an arbitrary order, like so:

[Description("Number of bars for fast EMA")]
[Gui.Design.DisplayName("\tThird parameter")]
[Category("Parameters")]
public int Fast
{
    get { return fast; }
    set { fast = Math.Max(1, value); }
}

[Description("Number of bars for slow EMA")]
[Gui.Design.DisplayName("\t\tSecond parameter")]
[Category("Parameters")]
public int Slow
{
    get { return slow; }
    set { slow = Math.Max(1, value); }
}

[Description("Number of bars for smoothing")]
[Gui.Design.DisplayName("\t\t\tFirst parameter")]
[Category("Parameters")]
public int Smooth
{
    get { return smooth; }
    set { smooth = Math.Max(1, value); }
}

And it works!

[whitmark]

Here is another approach that overcomes this issue:

http://www.ninjatrader-support.com/vb/showthread.php?t=4255

But yes, it would be nice if there was less visible way to do this with some type of sequence or order attribute that can be placed on each parameter.

Regards,

Whitmark

[NinjaTrader_Dierk]

Not sure how another attribute would be less visible...

[whitmark]

Dierk . . . not sure I follow your comment. By less visible I mean not require the use of a prefix (e.g., p01_FirstParameter) just to control the sequence and require renaming should an intervening new parameter be introduced.

In the thread of the link I posted, I point out there are clear inconsistancies in the sequence of parameters displayed in the parameter dialog and the sequence they are displayed at the top of the chart if you just manipulate the [Gui.Design.DisplayName]. Ideally, we're looking for an approach that controls the sequencing of both displayed items.

Thanks for sharing the "magic and mystery box" idea that will address only the parameter dialog sequencing and can be a bit kludgy to work with . . . as is the alternative method I use.

[Gui.Design.DisplayName("\t\t\t\t\t\t\t\t\t\t\t\t\t Twelth parameter")]

Would appreciate it if you can clarify whether this is something that can be improved upon in a future release or is this some limitation in C#.Net that we will need to learn to live with? Thanks.

Regards,

Whitmark

[NinjaTrader_Dierk]

The approach I posted below is the one working best for us at NT. Please feel free to take any alternate approach you like.

[KBJ]

[Gui.Design.DisplayName("\t\t\t\t\t\t\t\t\t\t\t\t\t Twelth parameter")]

Twelve tabs doesn't mean the 12th displaying parameter.

Since the binary value of a tab character ("\t") is less than that of text characters, the parameters with more tabs at the front would come first, not last; like so:

[Gui.Design.DisplayName("\t\t\t\t\t\t\t\t\t\t\t\tFirst parameter")]
[Gui.Design.DisplayName("\t\t\t\t\t\t\t\t\t\t\tSecond parameter")]
[Gui.Design.DisplayName("\t\t\t\t\t\t\t\t\t\tThird parameter")]
[Gui.Design.DisplayName("\t\t\t\t\t\t\t\t\tFourth parameter")]
[Gui.Design.DisplayName("\t\t\t\t\t\t\t\tFifth parameter")]
[Gui.Design.DisplayName("\t\t\t\t\t\t\tSixth parameter")]
[Gui.Design.DisplayName("\t\t\t\t\t\tSeventh parameter")]
[Gui.Design.DisplayName("\t\t\t\t\tEighth parameter")]
[Gui.Design.DisplayName("\t\t\t\tNinth parameter")]
[Gui.Design.DisplayName("\t\t\tTenth parameter")]
[Gui.Design.DisplayName("\t\tEleventh parameter")]
[Gui.Design.DisplayName("\tTwelth parameter")]

[whitmark]

KBJ, thanks for the clarification, I see now its important to know in advance how many parameters one is working with. Frankly, I didn't even seriously consider it long enough to realize the way it works. So, is it worth considering writing a small method that can make this even more structured and maintainable that can be used in the following manner:

ParmCount = 12;
N = 0
...
[Gui.Design.DisplayName(ParmTab( N++, ParmCount) + " First parameter")]
[Gui.Design.DisplayName(ParmTab( N++, ParmCount) + " Second parameter")]
...
[Gui.Design.DisplayName(ParmTab(N++, ParmCount) + " Tenth parameter")]
[Gui.Design.DisplayName(ParmTab(N++, ParmCount) + " Eleventh parameter")]
[Gui.Design.DisplayName(ParmTab(N++, ParmCount) + " Twelth parameter")]

Unsure if this type of method call is allowed. Also, this still doesn't solve the sequencing of the parameters at the top of the chart. Thoughts?

Regards,

Whitmark

[KBJ]

Good idea, in theory, but I can't see how to make it work for C#.

If this were C or C++, you could use some compile-time, preprocessor programming to implement this, but C#'s so-called "preprocessor" is too lame to be able to handle it.