OnStateChanged() - State.Terminated

[JohnSteinberg]

Hi,

I seem to be having problems with the OnStateChange() override when the state of my indicator goes to State.Terminated. I tested this outside my indicator in an indicator that has no other code in and I get the same results.

If my indicator is not on the chart and I add it through the indicators window, the method is called with the following states in this sequence:

- Terminated
- Configuring
- Terminated

This is obviously a problem as I cleanup any objects used in my indicator when the method is called with a state of Terminated.

The behavior when I remove my indicator from the chart through the indicator window seems OK, although it calls the method three times with a state of Terminated. I am guessing it is doing this because there are two other indicators on my chart and with mine it makes three.

Am I misunderstanding the flow of the OnStateChange() override completely? I attached two pictures, one with a code snippet that shows this behavior and one with the output I get when adding my indicator to a chart with my Print statements.

Thanks for any help.

Kind Regards,
John Steinberg

[NinjaTrader_Jesse]

Hello,

Thank you for the question.

This would be expected due to how the platform gets data from scripts to display the Menus. This happened in NT7 as well specifically with Initialize. You can find a note about this on the OnStateChange help page here: http://ninjatrader.com/support/helpG...=onstatechange

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.

When you actually apply the indicator, you are applying a different instance so the extra Prints would not be from the applied indicators instance specifically. This should not prevent any cleanup logic from happening, mainly you would need to ensure the objects being cleaned exist at that time of termination.

If you are having difficulties with the states in doing a specific task, could you provide a simple example of the logic being tried so I could look into what may be a more correct approach?

I look forward to being of further assistance.

[koganam]

Hello,

Thank you for the question.

This would be expected due to how the platform gets data from scripts to display the Menus. This happened in NT7 as well specifically with Initialize. You can find a note about this on the OnStateChange help page here: http://ninjatrader.com/support/helpG...=onstatechange




When you actually apply the indicator, you are applying a different instance so the extra Prints would not be from the applied indicators instance specifically. This should not prevent any cleanup logic from happening, mainly you would need to ensure the objects being cleaned exist at that time of termination.

If you are having difficulties with the states in doing a specific task, could you provide a simple example of the logic being tried so I could look into what may be a more correct approach?

I look forward to being of further assistance.

Jesse, I would have to say that your response is incomplete and borders on being actually wrong, in respect to the specific issue raised. As is clear in this post, there is a basic design flaw that you refuse to fix, because there is a hacky, kludgy workaround available.

ref: http://ninjatrader.com/support/forum...ght=terminated

The least you can do is to document the issue properly, as I have requested.

This happens to be the exact very issue that I anticipated would happen to developers who knew that they had to clean up resources, and tried to do so in the place that makes logical sense. That is why I asked that it be documented, so as to reduce this support burden, where each one of you support reps have to keep this arcana in mind, so that you can refer everybody to the thread.

[misova]

I have to agree with koganam.

I had very similar problems with strange sequence of termination states.
Current behavior is really unintuitive at least. It is hard to understand and does not make much sense to me.

What's worse, I had to add more boilerplate code, that handles this crazy termination sequences, so it introduces additional complexity. That should be avoided.

This termination sequence should be really improved.
It is pain, to handle it in our code..

[koganam]

I have to agree with koganam.

I had very similar problems with strange sequence of termination states.
Current behavior is really unintuitive at least. It is hard to understand and does not make much sense to me.

What's worse, I had to add more boilerplate code, that handles this crazy termination sequences, so it introduces additional complexity. That should be avoided.

This termination sequence should be really improved.
It is pain, to handle it in our code..

Way back when I was still in school getting my higher business education after my first degree, we learned that measurements show that when customers have a bad experience they tell an average of 23 people; they tell an average of 5 people when they have a good experience.

Extrapolating from those figures, they figured that for everyone who complains about a bad experience, there are about 20 who just walk away from the product quietly. I now see at least 6 developers complain about this on this public forum, so we can project that about 120 developers (partners or not) have either walked away from the problem by stopping any resource cleanup, and being willing to release buggy code, or have just walked away from NT8 altogether.

Maybe, you should try fixing the base issue.

Just my $0.02.

[NinjaTrader_Brett]

Thanks guys.

We did add this page to docs in response to koganams original thread: http://ninjatrader.com/support/helpG...fecycle_of.htm

We will also be making sure we link to that documentation from the OnStateChanged() documentation so its more easily found.

For now we will work to make it clear how the state system for NinjaScript works in NinjaTrader 8 based on the document above (welcome to any feedback to make that page better). I also am tracking the feedback on our NinjaTrader 8 state system in general. Any change to the state system likely would be deferred to our next major release cycle where we would have the ability to do code breaking changes where it makes sense and makes the quality of life better.

-Brett