Announcement

Collapse

Looking for a User App or Add-On built by the NinjaTrader community?

Visit NinjaTrader EcoSystem and our free User App Share!

Have a question for the NinjaScript developer community? Open a new thread in our NinjaScript File Sharing Discussion Forum!
See more
See less

Partner 728x90

Collapse

Multiple Instances of an Indicator sharing variable values

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

    #16
    Hello swcooke,

    If so, I respond with a unique ID that is given to the indicator
    It sounds like this is where the problem lies, is this a value the indicator is generating when loading? If so, that's likely not going work in contrast to how the state system works. It's expected that your indicator will have multiple instances created/destroyed and may also be reloaded quite a few times in its lifecycle. It looks like the post koganam replied with plays into this as well, in that post it seems the question is why Terminated is called when other scripts are loaded. You have a similar situation here in the fact that you are adding a new indicator and seeing your script reloaded, however, this is the normal expectation surrounding the actions being done.


    This is a very common approach to software licensing. If he opens the Indicator window to add another instance of the indicator, there is no reason for the first indicator, which already has a cookie, to check in again
    That may be true however it sounds like you are placing your expectation of something else towards NinjaScript. NinjaTrader and NinjaScript are a unique system with its own stipulations on how it works. Some concepts which apply toward other subjects may no longer be relevant here such as a single instance being used. In your previous example, two separate instances are applied to the chart. Your indicator will not be created only once in that example so I am not sure how this theory could work in this use case.

    If he did, what if he had 5 indicators in the chart? Each time he thinks about adding a Volume Indicator I have to check-in 5 times?
    If a new indicator is applied, yes. Based on how you are currently doing this check, If the check is in State.Configure it would be called every time the instance has its state called. In this example, that would be the already applied instances which get reloaded in addition to the new instance.

    Only additionally added Indicators need to check-in.
    Unfortunately, that is not really going to work this way, if you modify the indicator collection by adding new indicators and the platform triggers a reload, all of them are going to reload.


    Are you saying there is no way for an indicator instance (which is still remaining in the chart and has not been explicitly removed) to maintain the value of a simple string variable when other indicators are added?
    Correct, there is no suggested NinjaScript way to do this as that would not generally be a wanted result. Keeping old values would not be wanted with indicators because you could not trust that they recalculate when reloaded, they may retain old incorrect values. What you are expecting here sounds like the opposite of how NinjaScript works so you would need to design around that. NinjaScript is primarirly instance based, so a lot of new instances are created for various different actions and is also one of the primary purposes of having the State system. The State system lets the script know what stage it is in so it can configure its self as needed (or do a license check).




    Please let me know if I may be of further assistance.
    JesseNinjaTrader Customer Service

    Comment


      #17
      All that I seem to gather from that post is that you are checking if ChartControl != null. It seems to me that ChartControl is never null, in State.Configured or State.DataLoaded so I am not sure how that check does anything. I'd be thankful for an example. To recap, here is my challenge (which should not be so challenging):

      In State.Configured, my indicators do an asynchronous https POST request to validate a licensed user. If they are licensed, I return a unique string to them and set this string into a variable in the indicator. Before the https call, the string is initially set to "new-session." In this way, the variable acts as a bool that I can check to confirm if this instance of the indicator has already checked in and is licensed. However, if the user opens the window to edit my indicator settings or just add another indicator or add another instance of my indicator, the string is re-initialized to "new-session" and the indicator loses its' Licensed State. I am simply looking for a way to maintain this state for the life of the indicator.

      Just a note that this is a high level overview of my Licensing system. I store the machine id along with a unique id for the running instance of the indicator, on my server to prevent use of the indicators by multiple machines.

      Comment


        #18
        Thanks for your reply Jesse. I have just one final question based on something you wrote:

        Unfortunately, that is not really going to work this way, if you modify the indicator collection by adding new indicators and the platform triggers a reload, all of them are going to reload.
        You referred to an Indicator Collection in that statement which raises a question: Can an Indicator gain access to a list of other indicators in the chart (i.e. an Indicator Collection of some kind)? If so, do each of the Indicators have some unique characteristic that stays the same for the lifetime of the Indicator being in the chart?

        Comment


          #19
          Hello swcooke,

          You can iterate the ChartControl's Indicators collection however there is nothing unique in NinjaScript that I can suggest for this use case. You could experiment here with some C# items for this question but there is no documented "unique id" for NinjaScript objects for the purpose of tracking instances as you are asking. This is going to be a subject you would need to explore or experiment with to find something that works for you in contrast to what you have created. Otherwise, you may need to modify the license system to accommodate how your script works, this is likely what my suggestion would be. OnStateChange and the lifecycle of the script are a documented design pattern which is essentially being bypassed by trying to create caching for your licensing. It would likely be easiest to accommodate the indicator and how it works as you are free to create your license system however you want where we cannot change how NinjaScript works.

          Please let me know if I may be of further assistance.
          JesseNinjaTrader Customer Service

          Comment

          Latest Posts

          Collapse

          Topics Statistics Last Post
          Started by ghoul, Today, 06:02 PM
          3 responses
          14 views
          0 likes
          Last Post NinjaTrader_Manfred  
          Started by jeronymite, 04-12-2024, 04:26 PM
          3 responses
          44 views
          0 likes
          Last Post jeronymite  
          Started by Barry Milan, Yesterday, 10:35 PM
          7 responses
          20 views
          0 likes
          Last Post NinjaTrader_Manfred  
          Started by AttiM, 02-14-2024, 05:20 PM
          10 responses
          180 views
          0 likes
          Last Post jeronymite  
          Started by DanielSanMartin, Yesterday, 02:37 PM
          2 responses
          13 views
          0 likes
          Last Post DanielSanMartin  
          Working...
          X