User Defined Input Parameters

[erikp]

I recently ran into a minor obstacle while porting a strategy to NinjaTrader. I thought I'd document the issue and its solution to help other people that are new to the product.

When defining an input parameter for your strategy it's important that you do the following:

• The property you create should be in the "Parameters" region;
• the property should be assigned to the "Parameters" category;
• and, the internal variable that stores the value should be defined in the "Variables" region.

I was not defining variables in the "Variables" region, which caused the input parameters to be assigned to the "Misc" category rather than the expected "Parameters" category. This prevented me from being able to optimize my input parameters.

Here's a correct example:

#region Variables
private double mFixedFraction = 2.0;
#endregion
        
#region Properties        
[Description("The percentage of equity to risk on a given trade. For example, a value of 2.0 would mean that you're willing to lose 2% of the account's equity on a trade.")]
[Category("Parameters")]
public double FixedFraction {
    get { return mFixedFraction; }
    set { mFixedFraction = Math.Max(0, value); }
}
#endregion

To the NinjaTrader team: if possible it would be nice to remove the current requirement that variables be defined in the "Variables" region. Personally, I like to define a variable where I define a property.

Cheers,
Erik P

[NinjaTrader_JoshP]

This is a matter of C# and there is not much we can do. You can just as easily define your variables inside the OnBarUpdate or other methods, but they will have different inheritances depending on where you do it.

[shawnj]

<<
This is a matter of C# and there is not much we can do.
>>

Come on Josh, C# does not dictate what goes in a #region #endregion block. C# could care less what is inside a region block. A region block is just a way to visually organize your code. It's obvious that NinjaScript places some extra importance on the Variables and Properties regions.

What erikp is saying, and I totally agree with, is that in C# coding, it is very conventional to define a member variable (field) and it's associated property at the same time and in the same location. Ex:

private int myVal;
public int MyVal {
get { return myVal; }
set { myVal = value; }}

It's annoying (and poor code structure) to have to keep scrolling to the top of the code to define a new member variable and then having to scroll to the bottom of the code to define it's property.


<<
You can just as easily define your variables inside the OnBarUpdate or other methods, but they will have different inheritances depending on where you do it.
>>

You mean "scope", not "inheritances" don't you . Local variables don't have inheritance.

thanks,
shawnj

[NinjaTrader_JoshP]

shawnj,

By not much I mean this is not an area we can support at the moment therefore not much we can do. Yes you are right in the terminology.

Regardless, I will put it on the list of future considerations for you guys.

[shawnj]

Update:

After rereading my last reply, I though I came across a little strong - apologies to Josh.

So I though I better check out a little more thoroughly what I wrote.

I thought I would try to structure my code in the way that I described as the C# convention: Member Variables and their Properties defined in the same place.

So I did the following:
I deleted the lines: #region Variable, #endregion, #region Properties, #endregion.

I then moved all the Properties up to the top of the code each under it's associated member variable and it works . Clean compile and the Properties show up properly in the Indicators dialog. I think I will be using this as my default coding convention from now on. Take note erikp.

Ex:

public class myIndicator : Indicator
{

private int lineWidth = 1;
[Description("The Line Width.")]
[Category("Parameters")]
public int LineWidth
{
get { return lineWidth; }
set { lineWidth = Math.Max(0, value); }
}

protected override void Initialize()
{
}

protected override void OnBarUpdate()
{
}

}


thanks,
shawnj

[erikp]

Shawn,

Thanks for the tip. I'll try it out today.

Cheers,
Erik

[r2kTrader]

Amen brother.

<<
This is a matter of C# and there is not much we can do.
>>

Come on Josh, C# does not dictate what goes in a #region #endregion block. C# could care less what is inside a region block. A region block is just a way to visually organize your code. It's obvious that NinjaScript places some extra importance on the Variables and Properties regions.

What erikp is saying, and I totally agree with, is that in C# coding, it is very conventional to define a member variable (field) and it's associated property at the same time and in the same location. Ex:

private int myVal;
public int MyVal {
get { return myVal; }
set { myVal = value; }}

It's annoying (and poor code structure) to have to keep scrolling to the top of the code to define a new member variable and then having to scroll to the bottom of the code to define it's property.


<<
You can just as easily define your variables inside the OnBarUpdate or other methods, but they will have different inheritances depending on where you do it.
>>

You mean "scope", not "inheritances" don't you . Local variables don't have inheritance.

thanks,
shawnj