Push-Pop Unbalanced

[QuantKey_Bruce]

If you override FormatPriceMarker to return a null instead of a string, it crashes the platform with a push-pop unbalanced error. I understand one should not return null there (perhaps an empty string if there is no appropriate price marker) but the platform should not be allowed to crash in this circumstance.

Remember, please, that the type of this function's return is a string, and strings are by definition nullable.

[NinjaTrader_Emily]

Hello Bruce,

Thank you for your post.

I have moved this thread to the Indicator Development topic rather than the Technical Suppor topic since it has to do with custom NinjaScript development. I was unable to crash the platform with a test script that formats the price marker to null, though I did get the push-pop error you mentioned. What behavior are you describing as crashing the platform? Does NinjaTrader shut down completely on its own, or is something else happening? Please provide a reduced sample script that produces this behavior so I may test it on my end.

I look forward to your reply.

[QuantKey_Bruce]

The platform did not exit, but the rendering thread no longer was working correctly after that because it unable to recover from the push-pop error. So, if you reproduced the push-pop error, you have what you need I believe. It's as easy as return null; in that function.

[NinjaTrader_Emily]

The platform did not exit, but the rendering thread no longer was working correctly after that because it unable to recover from the push-pop error. So, if you reproduced the push-pop error, you have what you need I believe. It's as easy as return null; in that function.

A null string or returning null in general for the FormatPriceMarker() override is not a valid use case for FormatPriceMarker(). It is intended to change the format of the price and using a null string doesn't have anything to do with formatting the price. I will gladly submit a request to add a note to the help guide about using a null value resulting in errors when trying to render the price marker.

If the reason for using a null string is to try and hide the price marker, that is not the way to achieve it. You could use a plot that is transparent, set PaintPriceMarkers to false, use custom rendering to render plot values without a price marker, or a combination of those options in order to get different results from plots and price markers and how they are displayed or not on the chart.

Thank you for your time and your feedback.

[QuantKey_Bruce]

I appreciate you taking the time to offer some alternatives here. I actually understand how it works - I posted this thread originally because I know a lot of people have spent a lot of time chasing down this push pop thing, and this is the first time I have found a guaranteed way to make it happen. Even though it's something that cannot be recommended (returning a null string for a price marker) I thought that NT should check for null on this one and make it not crash beause having the push pop thing happen at all, even in the event of a programmer misunderstanding, is bad. It causes rendering to become unstable, and contributes to the belief that the platform has a lot of issues. It would be far better to simply catch the null and treat it as an empty string, rather than letting rendering fail in a way that cannot always be recovered.

[NinjaTrader_Emily]

I appreciate you taking the time to offer some alternatives here. I actually understand how it works - I posted this thread originally because I know a lot of people have spent a lot of time chasing down this push pop thing, and this is the first time I have found a guaranteed way to make it happen. Even though it's something that cannot be recommended (returning a null string for a price marker) I thought that NT should check for null on this one and make it not crash beause having the push pop thing happen at all, even in the event of a programmer misunderstanding, is bad. It causes rendering to become unstable, and contributes to the belief that the platform has a lot of issues. It would be far better to simply catch the null and treat it as an empty string, rather than letting rendering fail in a way that cannot always be recovered.

In the case that a developer comes across this type of error/behavior, we are glad to guide them through the debugging process to identify the potential cause and implement a resolution. If a platform user has imported custom scripts from a developer, they should understand the potential impact of installing these items as mentioned in the help guide here:

https://ninjatrader.com/support/helpGuides/nt8/index.html?using_3rd_party_add-ons.htm#UnderstandingTheImpactOfInstallingAdd-Ons

That said, thank you for the suggestion. I have submitted this as a feature request to the Development Team. I will follow up with an internal tracking number for your reference as soon as it is created.

Thanks in advance for your patience.

[QuantKey_Bruce]

Okay. I don't want to beat a dead horse here. But, saying "if some future programmer makes this mistake we'll guide them through figuring it out" is sort of missing that you could (and should) stop it from happening with just one line of guard code. It's crazy to think that to avoid putting one line of code to check for a null in the platform you and the other staff will spend who knows how many future hours helping who knows how many future people figure out what they did wrong. That has been my only point. If they can fix it great - that's why I posted about it. If you choose not to fix it and to spend support hours guiding future programmers through understanding why a hard-to-diagnose thing happened, well, I tried.

[NinjaTrader_Emily]

Hello Bruce,

Thanks for your patience.

The internal tracking number for your feature request is SFT-6133. Please reference this internal tracking number when contacting Platform Support if you ever have questions regarding this feature request.

When a feature request is implemented, you'll find a description of the new feature in the release notes:

• https://ninjatrader.com/support/help...ease_notes.htm

Thank you for using NinjaTrader.

[jeronymite]

Frankly, anything that crashes or otherwise causes aberrant behaviour and runtime errors must be treated as what it is: a BUG! It is not a "Feature Request".

QuantKey_Bruce is right to raise it (and persist in explaining it) so that it is recognised as the bug that it is and is slated to be fixed. This particular bug can be fixed with the simplest of "Defensive Programming 101" techniques and should be.

In fact, NinjaTrader itself promotes such defensive techniques in its own NinjaScript Best Practices, even stating explicitly in a code comment there "for safety, always check for null references before attempting to access an object even if you have once checked for null references earlier run-time". The use case may be different, but the principle is identical!

It's a bug, not a feature. Please fix.

Thanks.

[Leeroy_Jenkins]

We should probably vote for that 'feature request'