Announcement

Collapse
No announcement yet.

Partner 728x90

Collapse

What are the conventions for NT accessing an indicator's values?

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

    What are the conventions for NT accessing an indicator's values?

    I notice that after my indicator has finished handling all the bars "outside code" (i.e. NT8) is calling a data accessor property named IndicatorValue. That is, of course wrong -- it is one that the wizard created with a hard-coded index into Values[] -- and I have substantially reworked my handling of lines and plots since then. To tell the truth, I had forgotten all about that property.

    I'm not complaining -- it is up to me to make my indicator play nice. However, to do that I need to know what the conventions are. How does NT8 know what to call? Are specific property names involved, or is it something else?

    For anyone who does not know what I mean, here is the property, complete with its wrong offset:
    Code:
            [Browsable(false)]
            [XmlIgnore]
            public Series<double> IndicatorValue
            {
                get { return Values[3]; }
            }
    --EV
    Last edited by ETFVoyageur; 08-09-2015, 04:57 AM.

    #2
    Originally posted by ETFVoyageur View Post
    I notice that after my indicator has finished handling all the bars "outside code" (i.e. NT8) is calling a data accessor property named IndicatorValue. That is, of course wrong -- it is one that the wizard created with a hard-coded index into Values[] -- and I have substantially reworked my handling of lines and plots since then. To tell the truth, I had forgotten all about that property.

    I'm not complaining -- it is up to me to make my indicator play nice. However, to do that I need to know what the conventions are. How does NT8 know what to call? Are specific property names involved, or is it something else?

    For anyone who does not know what I mean, here is the property, complete with its wrong offset:
    Code:
            [Browsable(false)]
            [XmlIgnore]
            public Series<double> IndicatorValue
            {
                get { return Values[3]; }
            }
    --EV
    Plots are merely a visual representation of the data in the Values[] collection. You have to keep them in sync. Do you have >= 4 Plots defined?

    The Values[] collection is automatically populated, directly as a consequence of your definitions of the Plots.That is the purpose of using the Values[] collection to populate the Properties of the Plots.

    Am I misunderstanding?
    Last edited by koganam; 08-09-2015, 08:27 AM.

    Comment


      #3
      Originally posted by koganam View Post
      Plots are merely a visual representation of the data in the Values[] collection. You have to keep them in sync. Do you have >= 4 Plots defined?

      The Values[] collection is automatically populated, directly as a consequence of your definitions of the Plots.That is the purpose of using the Values[] collection to populate the Properties of the Plots.

      Am I misunderstanding?
      I see this has become a broader question.

      My original question: why is outside code calling "IndicatorValue"? I just confirmed, by generating another indicator with the wizard, the the symbol is whatever I say, not some NT standard. In the wizard code that symbol matches the name provided with AddPlot, but there is no reason to believe such a match would necessarily happen with a hand-generated indicator. So why was outside code calling it? Is there some NT convention I need to be aware of?

      =====

      My second point is that it looks as if the wizard has a bug and generates these accessor properties wrong. I just created a new indicator with three lines followed by two plots. Here are the two accessor properties the wizard generated:

      Code:
              [Browsable(false)]
              [XmlIgnore]
              public Series<double> ValueOfTheIndicator
              {
                  get { return Values[3]; }
              }
      
              [Browsable(false)]
              [XmlIgnore]
              public Series<double> ValueOfTheSignalLine
              {
                  get { return Values[4]; }
              }
      I also double checked and verified that the arrays work as I thought:
      • Lines[] gets one longer with each AddLine(...) call; Plots[] and Values[] are not affected
      • Plots[] and Values[] each get one longer with each AddPlot(...) call; Lines[] is not affected

      It seems to me that the accessor properties should be using index values 0 & 1, not 3 and 4. Unless I am missing something, that is a wizard bug. (FWIW: there is another wizard bug, which I already reported in the bugs area, that it generates AddPlot calls with a first argument that the compiler will not accept -- a Pen, when a Stroke is required.)

      =====

      Reviewing this has made me wonder: what is the difference between Plots[] and Values[]? Are they just synonyms? Why do both exist?

      --EV
      Last edited by ETFVoyageur; 08-09-2015, 11:16 AM.

      Comment


        #4
        Originally posted by ETFVoyageur View Post
        I see this has become a broader question.

        My original question: why is outside code calling "IndicatorValue"? I just confirmed, by generating another indicator with the wizard, the the symbol is whatever I say, not some NT standard. In the wizard code that symbol matches the name provided with AddPlot, but there is no reason to believe such a match would necessarily happen with a hand-generated indicator. So why was outside code calling it? Is there some NT convention I need to be aware of?
        =====
        Hm. That has nothing to do with the wizard. If you AddPlot(), NT creates another collection to hold its values, and adds the collection to the Values[] collection. You are then responsible for defining the property to access the Plot.
        My second point is that it looks as if the wizard has a bug and generates these accessor properties wrong. I just created a new indicator with three lines followed by two plots. Here are the two accessor properties the wizard generated:

        Code:
                [Browsable(false)]
                [XmlIgnore]
                public Series<double> ValueOfTheIndicator
                {
                    get { return Values[3]; }
                }
        
                [Browsable(false)]
                [XmlIgnore]
                public Series<double> ValueOfTheSignalLine
                {
                    get { return Values[4]; }
                }
        I also double checked and verified that the arrays work as I thought:
        • Lines[] gets one longer with each AddLine(...) call; Plots[] and Values[] are not affected
        • Plots[] and Values[] each get one longer with each AddPlot(...) call; Lines[] is not affected

        It seems to me that the accessor properties should be using index values 0 & 1, not 3 and 4. Unless I am missing something, that is a wizard bug. (FWIW: there is another wizard bug, which I already reported in the bugs area, that it generates AddPlot calls with a first argument that the compiler will not accept -- a Pen, when a Stroke is required.)

        =====
        That most assuredly looks funny. It also seems different from NT7, which does populate Values[] in the manner that you state.

        Given the evidence, it would appear that both AddLine() and AddPlot() are now being used to populate the Values[] collection. I wonder why, as the value of the Line never changes, so why does it need to be indexed? There must be something deeper that we are missing. (I hope?)
        Reviewing this has made me wonder: what is the difference between Plots[] and Values[]? Are they just synonyms? Why do both exist?

        --EV
        No. Plots are classes, so Plots[] is a collection of a collection of class objects. Values[] is a collection of a collection of primitives, (always?) doubles.

        Comment


          #5
          Given the evidence, it would appear that both AddLine() and AddPlot() are now being used to populate the Values[] collection. I wonder why, as the value of the Line never changes, so why does it need to be indexed? There must be something deeper that we are missing. (I hope?)
          I must not have been clear. That is not happening. AddLine() causes an increase in the length of only Lines[]. AddPlot() causes an increase in the length of Plots[] and Values[] (but not Lines[]). All of that looks fine to me.

          The bug I see is that the new indicator wizard is acting as if both were being added to Values[]. It generates offsets in the accessor properties that would be correct IFF both lines and plots were added to Values[]. They are not, but the wizard seems to think they are.

          BTW: I still wonder why outside code was calling my accessor property. I need to know whether there is some convention I need to be aware of remaining consistent with.

          --EV
          Last edited by ETFVoyageur; 08-09-2015, 05:51 PM.

          Comment


            #6
            Originally posted by ETFVoyageur View Post
            I must not have been clear. That is not happening. AddLine() causes an increase in the length of only Lines[]. AddPlot() causes an increase in the length of Plots[] and Values[] (but not Lines[]). All of that looks fine to me.

            The bug I see is that the new indicator wizard is acting as if both were being added to Values[]. It generates offsets in the accessor properties that would be correct IFF both lines and plots were added to Values[]. They are not, but the wizard seems to think they are.

            BTW: I still wonder why outside code was calling my accessor property. I need to know whether there is some convention I need to be aware of remaining consistent with.

            --EV
            No, it was my response that was unclear. You have stated what I was trying to say, and said so poorly.

            Still if that is the case, then one would expect to see an "Index out of bounds" error, would we not? It gets curiouser and curiouser.

            As to your code access by outside code, that would be hard to track down without seeing the code. My Plots are only accessed when I write specific code to access them.

            Comment


              #7
              Originally posted by koganam View Post
              No, it was my response that was unclear. You have stated what I was trying to say, and said so poorly.

              Still if that is the case, then one would expect to see an "Index out of bounds" error, would we not? It gets curiouser and curiouser.

              As to your code access by outside code, that would be hard to track down without seeing the code. My Plots are only accessed when I write specific code to access them.
              You are correct about the exception. I was aware of the bad code the wizard generates (I reported that at the time). Since I do not use it I had not gotten around to cleaning it up yet. The problem became immediate for me when an out of bounds exception got thrown. I put a breakpoint there, retried to be sure, and my breakpoint got hit. Visual Studio showed only two things on the stack: outside code, and my breakpoint.

              I guess the outside code access will remain a mystery. It does not sound like anything I need to worry about. I hope they fix the wizard to generate correct code, though.

              --EV

              Comment


                #8
                Hello ETFVoyageur,

                Thank you for reporting this item here.

                Comment

                Latest Posts

                Collapse

                Topics Statistics Last Post
                Started by Perr0Grande, Today, 08:16 PM
                0 responses
                2 views
                0 likes
                Last Post Perr0Grande  
                Started by elderan, Today, 08:03 PM
                0 responses
                5 views
                0 likes
                Last Post elderan
                by elderan
                 
                Started by algospoke, Today, 06:40 PM
                0 responses
                10 views
                0 likes
                Last Post algospoke  
                Started by maybeimnotrader, Today, 05:46 PM
                0 responses
                12 views
                0 likes
                Last Post maybeimnotrader  
                Started by quantismo, Today, 05:13 PM
                0 responses
                7 views
                0 likes
                Last Post quantismo  
                Working...
                X