UI.xml crashing NinjaTrader after indicator updates

[Harry]

When I write an indicator update for an existing indicator and add a single property to the properties section, this often results in a disaster, as users can no more add the indicator to a chart but freeze NinjaTrader.

Only users are affected that have changed the indicator presets and saved them in the lower right corner of the indicator dialogue box.

When the user has customized the indicator and saved the presets, these will be stored in the UI.xml file. When the indicator is uninstalled or removed, those settings are left in the UI.xml file as garbage and cannot be deleted.

When installing a new version of the indicator that comes with an additional property the garbage left in the UI.xml file often freezes NinjaTrader and a complete reinstallation of NinjaTrader may become necessary.

My questions:

(1) Is it possible to remove the offending section (indicator settings in UI.xml file as stored in "Indicator Presets") and store the UI.xml file without the leftovers from the prior version?

(2) Is there any other way to replace the offending UI.xml file with a new one?

I have not been successful in deleting the offensive code from the UI.xml file manually. Whatever I have tried, NinjaTrader has stored the old UI.xml file containing the garbage after a restart.

[stafe]

Harry, i just delete the UI.xml file and NT rebuilds a new one upon restart - had a problem updating a TTP vol analysis package - some things are lost but it hasn't been a huge burden yet...

[Harry]

What are the side effects when deleting the UI.xml file?

I noticed that all indicator default settings are lost, but these can be easily rebuilt.

[NinjaTrader_ChelseaB]

Hello Harry,

Thanks for reporting this behavior.

Is this with open source scripts, assemblies, or both?

I will need to do some testing on this and I will let you know what I find.

I appreciate your patience.

[stafe]

the main thing that i notice is the disappearance of my instrument list but when i load the workspace everything is fine other than yes, some indicator presets are gone and i go back and preset them again... I first tried this maneuver when i was having repeated crashing problems running an order flow package that uses tick replay... but it's more useful when dealing with the UE error when loading an updated piece of code...




p.s. happy to share - if my hunch serves me right i'm using your OpeningRange software and am very happy with it... kudos

[Harry]

Hello Harry,

Thanks for reporting this behavior.

Is this with open source scripts, assemblies, or both?

I will need to do some testing on this and I will let you know what I find.

I appreciate your patience.

Hello Chelsea,

Thank you for your answer. I have definitely observed the issue both with assemblies and indicators. There are two necessary conditions for the thing to happen:

(1) The user changed the default settings of the indicator, such that the new settings were stored under <IndicatorPresets> in the UI.xml file.

(2) The user imports a new version of the indicator which has some properties added within the property section.

Now when the user tries to add the indicator to a chart, the indicator will not show up in the lower section of the indicator dialogue box, when the user selects the "Apply" button. Instead NinjaTrader will throw an exception "Unhandled exception: There is an error in XML document (0,0)." and freeze.

This shows that there is a conflict between the default settings stored in the UI.xml file for the prior version of the indicator and the new updated indicator.


Solution

At the stage where the new indicator freezes NinjaTrader, it is difficult to fix the problem. I have tried to delete the indicator presets manually by editing the UI.xml file. Although this is possible, NinjaTrader will overwrite the modified UI.xml file with the original file each time that it is restarted. This approach does not solve the issue. Deleting the entire UI.xml file works, but I will lose all my presets for data seríes, indicators, draw objects, etc.

The only way that I have found to get rid of the remainders of the old indicator version is the following procedure

- remove the new indicator version
- install the previous version of the indicator
- open the indicator dialogue box and restore the indicator default settings
(yes - this does remove all of the offending code in the UI.xml file!)
- install the new version of the indicator again

Now the new version of the indicator can be added to a chart without throwing an XML exception.

[NinjaTrader_ChelseaB]

Hello Harry,

I have been attempting to reproduce this behavior with an open source script but I am currently unable.

Are you using 8.0.14.2?

What are the steps to reproduce?

Currently, I have created an empty indicator with a single Input. I've saved the preset for the indicator, then changed the name of the input, and loaded a new instance. No freezing or crashing.

I've then added a second input, restarted, and added a new instance. No freezing or crashing.

Are there any steps I am overlooking?

[Harry]

Hello Harry,

I have been attempting to reproduce this behavior with an open source script but I am currently unable.

Are you using 8.0.14.2?

What are the steps to reproduce?

Currently, I have created an empty indicator with a single Input. I've saved the preset for the indicator, then changed the name of the input, and loaded a new instance. No freezing or crashing.

I've then added a second input, restarted, and added a new instance. No freezing or crashing.

Are there any steps I am overlooking?

I am using NT 8.0.14.2, but this issue is not new. It has also happened with prior releases of NinjaTrader. I have observed the behavior on several different machines, but do not know how to produce it on my own.

Please let me check whether I can reproduce it somehow on my side.

[Harry]

Chelsea,

I have been able to reproduce the behavior with a complex indicator, but will now try to develop a scenario with a simpler indicator to make it easier for you to reproduce on your side.

Your help is appreciated.

[aligator]

I am using NT 8.0.14.2, but this issue is not new. It has also happened with prior releases of NinjaTrader. I have observed the behavior on several different machines, but do not know how to produce it on my own.

I totally agree. I have been experiencing the same scenario and freezing for some times now with other versions too, but did not suspect that the UI.xml file be the issue. Makes sense now.

[Harry]

Conflict between updated enum and UI.xml file

I have now been able to isolate the issue.

It is a conflict between the old UI.xml file and an enum which has its values changed.

When I made the last indicator update, I had also changed the wording of an enum value, replacing "Full_Session" with "Trading_Hours", as the former expression was slightly incorrect. Changing the string value of the enum caused NinjaTrader to throw an exception after the update.

There is a line in the indicator presets of the UI.xml file that reads

<SessionType>Full_Session</SessionType>

SessionType refers to an enum that could originally take the values "Daily_Bars" or "Full_Session". For the new version of the indicator the values "Daily-Bars" or "Trading_Hours" are permitted. As the UI.xml has stored the old value "Full_Session" of the enum, it is in conflict with the new enum which does not allow for that value.

When the updated indicator is first added to a chart, NinjaTrader tries to load the presets and set the enum value to "Full-Session". This is what causes the exception "Unhandled exception. There is an error in XML document (0,0)"

Basedon this observation, it should be simple to build a small indicator with an enum and then change the preset enum value and make it freeze after the update.

[NinjaTrader_ChelseaB]

Hello Harry,

I'm still trying to reproduce.

I've made an enum in a custom namespace. Made an input in an indicator for that enum. Saved a preset and also saved an instance of the indicator in the workspace.

I then changed the enum name and changed the input name and i've restarted and tested pulling the preset and checked for any errors that might be appearing when loading the workspace.

I am still not producing errors. Below is a link to a video of the test.

https://drive.google.com/file/d/1O_cJ5L44-VVLeD_U6X9787dKz54ECPV1/view?usp=sharing

Are there any steps I've missed?

[Harry]

As I have already reproduced the issue on my side, it should be easier for me to produce a simple custom indicator in order to expose the problem.

Otherwise, for your custom indicator, you would probably have to replace "Value2" with "Value3" inside the namespace EnumPresetTestEnums. For the test please follow these three steps:

(1) Select "Value 2" as preset value in the indicator dialogue box (as you did in the little video).

(2) Then edit the indicator and replace "Value2" with "Value3" in all places where it occurs and compile.

(3) Then add the modified indicator to a chart.

The UI.xml file will now search for "Value2" to apply the default settings. "Value2" no longer exists, which in turn triggers the XML exception.

[NinjaTrader_ChelseaB]

Hello Harry,

Got it, thanks!

Changing the values of the enum triggers the error.

I've got this reported to our development and I've got tracking ID #NTEIGHT-12941 for this behavior.

As new versions of NinjaTrader become available please check the release notes to see if this item was changed or corrected.

Below is a public link.

https://ninjatrader.com/support/helpGuides/nt8/en-us/release_notes.htm

[Harry]

Hello Chelsea,

Thank you for your efforts! It took me a few hours of testing as well to find out the cause of the problem. I think it is a pretty rare case, because usually when updating an indicator you would not do things like

- adding or removing any NinjaScript parameters
- or changing enum values

This would also break all strategies that use the indicator. Therefore it is not a standard case.

Also I understand that after an update of any indicator default settings shall be maintained. However, in case that there is an incompatibility it would be nice

- to catch the exception
- and restore the default settings of the indicator to avoid further problems

In this case the indicator presets in the UI.xml file are just a leftover from the prior version of the indicator - just garbage that prevents the new indicator from working as expected.