NT messing with Lines[] when not wanted !!!

[ETFVoyageur]

Another case of NT doing way too much !@$!@#$ FM !!!

I want to allow the user to be able to enable/disable individual lines by toggling enable/disable properties in the Indicators dialog. So in Initialize() I just refrain from adding the unwanted line. That means I now have only two lines, instead of the previous 3 lines Add()ed. At the end of Initialize() all is fine -- Lines[] has the right things, and only the right things -- two lines.

The problem is that on entry to OnStartup() NT has taken it upon itself to restore the unwanted 3rd line to Lines[]! Yuck! NT restores Lines[] to a now-obsolete state! It looks as if I am going to have to clean up Lines[] myself on entry to OnStartup(). Perhaps I can save Lines[] at the end of Initialize() and restore it on entry to OnStartup() ... I just HATE having to do battle with obscure NT foolishness.

If anyone knows how to tell NT to not mess with the Lines[] array after I set it up in Initialize(), please let me know!

--EV

P.S. Please do not bother to remind me of setting unwanted lines transparent. That can work, but it's pretty much a kludge. I did that in a recent indicator -- that's what got me to make persistent data properties work. Getting it right from a usability point of view is a lot easier said than done, so I want this more straightforward way to work -- just don't add in lines you don't want. Removing unwanted lines is also a lot cleaner GUI -- if you disable it, it disappears from the GUI as well as from the chart.

[ETFVoyageur]

OK -- here's the next step. Sort of works, but not quite.

After Add()ing the lines I want (in Initialize()) I make a copy of the Lines[] array, since it is in the state I want.

After leaving Initialize(), NT tries to restore the obsolete Lines[], but I counter with forcing the correct one from ModifyProperties() (which is called from GetProperties()). That almost works:

• It works fine in the Indicators dialog -- the disabled line is no longer in the GUI.
• The problem is that when you click "OK" or "Apply" the line still shows in the indicator panel on the chart -- but if you click "Apply" twice the line goes away in the chart as well. Similarly, if you click "OK" the line remains in the chart, but if you bring the dialog back up, change nothing, click "OK" again the chart is now fine (i.e. the line is gone).

Interesting ... NT does not chart what the Indicators dialog shows! It plots a line that is not in the dialog! Yuck! Very strange that when clicking "Apply" or "OK" everything but the lines gets replotted as far as I can see.

Question: is there some way I can force the lines to get plotted, using the now-current Lines[] array?

--EV

[sledge]

http://ninjatrader.com/support/forum/showpost.php?p=336980&postcount=7

[ETFVoyageur]

Thanks for the suggestion.

That is a 2009 post that is no longer correct. For example, it says "My workaround to overcome a problem of only default input values available during Initialize() ..."

That may have been true then, but it is not true today. NT initializes all of the persistent properties, including everything backing up the Indicators dialog, to their correct values before calling Initialize().

That said, I do not see how it addresses the issue I am raising -- that I can force Lines[] to be the way I want it, and the Indicators dialog shows that correctly, but it takes two times clicking the "Apply" button for it to get plotted correctly on the chart.

My problem occurs well after Initialize(). Lines[] is just the way I want it when I return from Initialize().

--EV

[ETFVoyageur]

Another noteworthy point -- reminiscent of my issues with adding fewer instruments than Instruments[] had previously:

• If I change a line from disabled to enabled, i.e. increasing the size of Lines[], all is just fine. Both the dialog and the chart get updated correctly the first time I click "Apply".
• If I change a line from enabled to disabled, i.e. decreasing the size of Lines[], the problem occurs -- the first "Apply" updates the dialog, but it takes a second "Apply" to update the chart!

I'm seeing a pattern here .. with both Instruments[] and Lines[] NT misbehaves if one decreases the array size. I posted the work-around for the Instruments[] problem in an earlier thread. I do not yet known the fix for the Lines[] problem.

I would set the disabled line transparent, except that it is long gone and with all of the NT cloning going on I have no idea which Line object it is using to draw the unwanted line.

--EV

[ETFVoyageur]

OK -- problem appears to be solved -- fighting against NT all the way. Here's the fix:

• When done adding lines in Initialize() save a copy of Lines[], because now it is known to be correct
• In ModifyProperties() {called from GetProperties()} restore Lines[] from the saved copy, because NT will have substituted an obsolete copy by then. This restoration makes the Indicators dialog behave correctly.
• In OnStartup() restore Lines[] from the saved copy, because NT will once again have forced an obsolete version. This restoration is what it takes for the chart to get updated when it should (i.e. no longer a need to press "Apply" twice).

All I am trying to do is allow the user to disable a line -- have it disappear from both the GUI and the chart. The user can then re-enable it and have it reappear both places. That should not be so difficult. I should not have to figure out every place NT mistakenly restores an obsolete version of Lines[], and then counteract it. There's just too much FM going on; it's no wonder it is not quite right for the less common cases.

BTW: this thread answers the question that has been posed in the past about how to remove a line. The consensus has been that it is not possible -- that the best you can do is kludge around with setting the line transparent (which, by the way, is a lot harder than you think if you do it really right). The correct answer is that truly removing the line (from both the GUI and the chart) is possible, as demonstrated in this thread, albeit more difficult than it should be.

SUPPORT folks: This is the second similar sort of thing I have run across recently. I suppose it is too much to ask that either case get cleaned up in NinjaTrader 7, but you really should make sure that it is fixed in NijaTrader8 -- that this nonsense does not get propagated to NinjaTrader 8.

--EV

[NinjaTrader_PatrickH]

Hello EV,

Thank you for your posts and suggestion.

[ETFVoyageur]

Patrick,

You are welcome.

One of the things that has become very clear to me recently is that NT really does not like you to do different things on different passes through Initialize(). If user configuration choices in the Indicators dialog require doing anything different in Initialize() that affects anything NT is trying to persist then you really have your work cut out for you, and you have to understand more than is documented about how NT handles persisting information.

Matthew seems to think this will be addressed by providing an overrideable Clone() function in NT8. I hope he is correct. I am anxiously awaiting the documentation of that feature to verify that it does indeed address the needs.

--EV