Remember, please, that the type of this function's return is a string, and strings are by definition nullable.
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!
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
NinjaTrader
Push-Pop Unbalanced
Collapse
X
-
Push-Pop Unbalanced
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.Tags: None
-
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.Emily C.NinjaTrader Customer Service
-
Originally posted by QuantKey_Bruce View PostThe 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.
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.Emily C.NinjaTrader Customer Service
Comment
-
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.
Comment
-
Originally posted by QuantKey_Bruce View PostI 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.
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.Emily C.NinjaTrader Customer Service
Comment
-
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.
- Likes 2
Comment
-
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:Thank you for using NinjaTrader.Emily C.NinjaTrader Customer Service
Comment
-
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.
- Likes 1
Comment
-
Latest Posts
Collapse
Topics | Statistics | Last Post | ||
---|---|---|---|---|
Started by fx.practic, 10-15-2013, 12:53 AM
|
5 responses
5,404 views
0 likes
|
Last Post
by Bidder
Today, 12:22 AM
|
||
Started by Shai Samuel, 07-02-2022, 02:46 PM
|
4 responses
95 views
0 likes
|
Last Post
by Bidder
Today, 12:11 AM
|
||
Started by DJ888, Yesterday, 10:57 PM
|
0 responses
8 views
0 likes
|
Last Post
by DJ888
Yesterday, 10:57 PM
|
||
Started by MacDad, 02-25-2024, 11:48 PM
|
7 responses
159 views
0 likes
|
Last Post Yesterday, 10:23 PM | ||
Started by Belfortbucks, Yesterday, 09:29 PM
|
0 responses
8 views
0 likes
|
Last Post
by Belfortbucks
Yesterday, 09:29 PM
|
Comment