• If this is your first visit, you will have to register before you can post. To view messages, please scroll below and select the forum that you would like to visits. Questions? Be sure to check out the Forum FAQ.

Announcement

Collapse
No announcement yet.

Partner 728x90

Collapse

User Defined Input Parameters

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    User Defined Input Parameters

    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:
    Code:
    #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

    #2
    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.
    Josh P.NinjaTrader Customer Service

    Comment


      #3
      <<
      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

      Comment


        #4
        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.
        Josh P.NinjaTrader Customer Service

        Comment


          #5
          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

          Comment


            #6
            Shawn,

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

            Cheers,
            Erik

            Comment


              #7
              Amen brother.

              Originally posted by shawnj View Post
              <<
              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

              Comment

              Latest Posts

              Collapse

              Topics Statistics Last Post
              Started by Ivantr, Yesterday, 05:24 PM
              1 response
              10 views
              0 likes
              Last Post NinjaTrader_Marco  
              Started by ralett, Yesterday, 06:20 PM
              3 responses
              27 views
              0 likes
              Last Post ralett
              by ralett
               
              Started by trader252, Yesterday, 08:38 PM
              1 response
              5 views
              0 likes
              Last Post NinjaTrader_ChrisSch  
              Started by grizzlytrader, Yesterday, 06:24 AM
              1 response
              24 views
              0 likes
              Last Post NinjaTrader_ChelseaB  
              Started by andrewtrades, Yesterday, 01:43 PM
              1 response
              6 views
              0 likes
              Last Post NinjaTrader_ChelseaB  
              Working...
              X