Announcement

Collapse
No announcement yet.

Partner 728x90

Collapse

Exception crossover from other custom indicator

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

    Exception crossover from other custom indicator

    I have two custom indicators...

    MyCustomIndicator1 compiles and runs properly.
    I save and close the workspace I use to test it. Not that it matters, but it is a port of a production NT7 indicator.

    I open the workspace I use for MyCustomIndicator2. It compiles and runs properly, but oddly when executed (passing through it's Terminated state on a restart) I see the following output, clearly coming from the try/catch block I have on MyCustomIndicator1:

    Terminated....from !!!! MyCustomIndicator1 !!!!EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object.
    at NinjaTrader.NinjaScript.Indicators.MyCustomIndicat or1.OnStateChange()


    Oddly, the State.Terminated block in MyCustomIndicator1 does not generate this same error when MyCustomIndicator1 is executed.
    If I remove MyCustomIndicator1.cs from the indicators folder, recompile MyCustomIndicator2, the exception no longer appears in the output.

    I don't know if it's related, but it if I prepend this to that exception handler print statement, it shows MyCustomIndicator1(NinjaTrader.Gui.Tools.SimpleFon t).
    Is this trying to tell me that there is a SimpleFont variable in MyCustomIndicator1 that is un-initialized and somehow causing an overflow of sorts to MyCustomIndicator2?

    I also notice that the statement Print("\tVerifying license... for "+this.ToString()); from the State.Defaults block of MyCustomIndicator1 appears on the output as well (and just to reiterate, that's when executing MyCustomIndicator2 and all charts and/or workspaces containing MyCustomIndicator1 are closed. Note, that the Print statement I have after the license check in MyCustomIndicator1 is not executed (which of course I wouldn't expect it to be, since that indicator is not the one being executed).

    Has anyone else reported anything similar to this?
    At this point I don't know if it's a defect somewhere in my code or in NT8.
    Any clues on how to resolve this, would be greatly appreciated.

    #2
    Hello CriticalTrader,

    Can you provide an example script that demonstrates this behavior?

    I am not able to reproduce this with any two indicators or strategies that are in NinjaTrader or custom written to test with.

    To export a NinjaTrader 8 NinjaScript do the following:
    1. Click Tools -> Export -> NinjaScript...
    2. Click the 'add' link -> check the box(es) for the script(s) you want to include
    3. Click the 'Export' button
    4. Enter a unique name for the file in the value for 'File name:'
    5. Choose a save location -> click Save
    6. Click OK to clear the export location message

    By default your exported file will be in the following location:
    • (My) Documents/NinjaTrader 8/bin/Custom/ExportNinjaScript/<export_file_name.zip>


    Below is a link to the help guide on Exporting NinjaScripts.
    Chelsea B.NinjaTrader Customer Service

    Comment


      #3
      Ya, thought you might ask ;-(
      Unfortunately, MyCustomIndicator1 has several hundred lines of proprietary code that I am unwilling to share. If I can reproduce it in a version that is shareable, I will let you and the forum know.
      Was primarily wondering if anyone has observed a similar situation.
      In any case, if I discover it is a defect in my code, I will let you know that as well.
      I appreciate your offer.

      Comment


        #4
        Well after whittling down several hundred of lines of code to just a few, I finally figured out the cause of the Exception raised in MyCustomIndicator1 when executing MyCustomIndicator2. Turns out I neglected to check for Bars!=null. However, what is most troubling is that this never gets raised when MyCustomIndicator1 is executed and for some unknown reason, portions of code in MyCustomIndicator1 are being executed when the Indicator panel is opened from the chart with MyCustomIndicator2, including State=SetDefaults and State=Terminated where the test for null bars was lurking causing the exception! This seems to be a NT defect to me; I would expect better isolation between custom indicators.

        I've attached the 2 indicators. One indicator was added to one chart and the other to another chart. Open an Output window to observe the trace prints statements. Note, that when I first encountered this problem, no chart with MyCustomIndicator1 was even open.
        Attached Files

        Comment


          #5
          Originally posted by CriticalTrader View Post
          Well after whittling down several hundred of lines of code to just a few, I finally figured out the cause of the Exception raised in MyCustomIndicator1 when executing MyCustomIndicator2. Turns out I neglected to check for Bars!=null. However, what is most troubling is that this never gets raised when MyCustomIndicator1 is executed and for some unknown reason, portions of code in MyCustomIndicator1 are being executed when the Indicator panel is opened from the chart with MyCustomIndicator2, including State=SetDefaults and State=Terminated where the test for null bars was lurking causing the exception! This seems to be a NT defect to me; I would expect better isolation between custom indicators.

          I've attached the 2 indicators. One indicator was added to one chart and the other to another chart. Open an Output window to observe the trace prints statements. Note, that when I first encountered this problem, no chart with MyCustomIndicator1 was even open.
          Just another example of this: http://ninjatrader.com/support/forum...ad.php?t=83608

          There is a kludgy, hacky, workaround in that thread. NinjaTrader would appear to have decided that that is a solution rather than a workaround.

          Comment


            #6
            Thanks for the reply koganam. Wow... the time we are all wasting chasing daemons.
            I can see now that my particular situation was only the tip of the potential inadvertent cross-pollination issues NT Support is destined to deal with.

            It should at least be documented in the HelpGuide; would be nice to include a theory of operations with a design rationale for this as well. It never even occurred to me that State.SetDefaults and State.Terminated for every custom indicator will be executed when I open the indicator dialog while working on another. After reading the other threads, I can't say I understand it yet.... can someone at NT please explain the rationale clearly?

            If I didn't have Print() statements in MyCustomIndicator1, I would not have noticed its code being executed while working with MyCustomIndicator2.

            If I didn't have a try/catch clause in my State.Terminated MyCustomIndicator1, I wouldn't have noticed the defect that only manifests when MyCustomIndicator2 opens and closes the indicator dialog.

            Comment


              #7
              Hello CriticalTrader,

              From the help guide:
              "Viewing any UI element which lists NinjaScript classes (such as the Indicators or Strategies window, a chart's Chart Style dropdown menu, etc.) will initialize all classes of that Type when it is opened, which causes each script to enter State.SetDefaults, even if it is not actively configured or running in any window. It is important to keep this in mind when adding logic within State.SetDefaults in OnStateChange(), as this logic will be processed each time the script is initialized. For example, opening the Indicators window will trigger State.SetDefaults for all indicators in the system, and closing the Indicators window will trigger State.Terminated for all Indicators. In addition, disconnecting or connecting to a data provider can cause State transitions for any currently active scripts."

              Are you wanting to change the language in this note? If so, how are you wanting this re-worded?
              http://ninjatrader.com/support/helpG...tatechange.htm
              Chelsea B.NinjaTrader Customer Service

              Comment


                #8
                Obviously I missed (or certainly did not fully appreciate) that warning. I do apologize for asserting a lack of documentation.
                While I would not have expected this sort of interaction and disagree with the design approach, I'm certain your developers have good a rationale for initializing all classes in the UI, even if they are not selected.

                A continuing lesson for all to take... it pays to read every road-sign.

                Thank you Chelsea. Your team is doing a great job and has produced an outstanding product.

                Comment


                  #9
                  Originally posted by NinjaTrader_ChelseaB View Post
                  Hello CriticalTrader,

                  From the help guide:
                  "Viewing any UI element which lists NinjaScript classes (such as the Indicators or Strategies window, a chart's Chart Style dropdown menu, etc.) will initialize all classes of that Type when it is opened, which causes each script to enter State.SetDefaults, even if it is not actively configured or running in any window. It is important to keep this in mind when adding logic within State.SetDefaults in OnStateChange(), as this logic will be processed each time the script is initialized. For example, opening the Indicators window will trigger State.SetDefaults for all indicators in the system, and closing the Indicators window will trigger State.Terminated for all Indicators. In addition, disconnecting or connecting to a data provider can cause State transitions for any currently active scripts."

                  Are you wanting to change the language in this note? If so, how are you wanting this re-worded?
                  http://ninjatrader.com/support/helpG...tatechange.htm
                  You might want to add verbiage in there particularly addressing the issue with State.Terminated, and the suggested solution to the problem, where, because of the design, State.Terminated can be triggered and can generate unexpected, undesired side effects, because resources get terminated or reset, as described in this thread.

                  Comment


                    #10
                    Hello koganam,

                    I've sent your suggestion to add an example to our help guide of a coding style to determine if a script has entered certain states to our Product Management for consideration.
                    Thanks for making this suggestion.
                    Chelsea B.NinjaTrader Customer Service

                    Comment

                    Latest Posts

                    Collapse

                    Topics Statistics Last Post
                    Started by wzgy0920, 04-20-2024, 06:09 PM
                    2 responses
                    26 views
                    0 likes
                    Last Post wzgy0920  
                    Started by wzgy0920, 02-22-2024, 01:11 AM
                    5 responses
                    32 views
                    0 likes
                    Last Post wzgy0920  
                    Started by wzgy0920, Yesterday, 09:53 PM
                    2 responses
                    49 views
                    0 likes
                    Last Post wzgy0920  
                    Started by Kensonprib, 04-28-2021, 10:11 AM
                    5 responses
                    192 views
                    0 likes
                    Last Post Hasadafa  
                    Started by GussJ, 03-04-2020, 03:11 PM
                    11 responses
                    3,234 views
                    0 likes
                    Last Post xiinteractive  
                    Working...
                    X