Failed to call OnRender() for chart object 'Line':

[soulfx]

Failed to call OnRender() for chart object 'Line': 'External component has thrown an exception.' 11424
Fixed
NinjaScript
Resolved some scenarios of error "Failed to call OnRender() for chart object 'Line': 'External component has thrown an exception.'" - in the v6.0 release notes but is still an issue and partially resolved.

Hello, i am asking other users if they are also experiencing this error with random crashes consistently pointing this error in the log files. And yes i have already reported this several times for past weeks in email to support and nothing is forthcoming.

I know of a vendor who is also stuck with this exact issue and still not resolved. I am not getting much in the way of information from Ninja so this is the only way i know to communicate with the community to get some assistance to track this error. It has been hampering my own progress with random crashes and i would like this resolved. So if anyone has anything to share on this it would be appreciated
thanks

[JerryWar]

I have been getting this error for several days crashing Ninja. I reported it was told it was "MY CODE". I was told to check my variables for nulls. I put a trap around every single draw.Line to check every single parameter and print them out if they were out of range or zero or null. No trap never triggered but I got two crashes today on Line exceptions. I have never had this error before and it seems like after their fix I am now having to deal with it. After reading your post I think I am going back to NT7.

[NinjaTrader_Jim]

Hello soulfx and JerryWar,

When I have seen OnRender() errors, they usually point to 2 types of scenarios.

The first scenario is that the custom NinjaScript is using OnRender() improperly and is throwing issue.

The second scenario involves a corrupt chart/workspace/template in which, for example, an abrupt shut down of the platform has damaged the files that store the information to recreate these charts.

You may use Safe mode as a diagnostic tool to verify that workspaces or custom assemblies are part the issue. If the platform behaves as it should in Safe Mode, we must troubleshoot the workspace and possibly the indicators used as well.

Safe Mode will prevent NinjaTrader from:

• Loading workspaces.
• Connecting on start-up.
• Loading custom assemblies.
• Getting instrument updates from the server.

To enable safe mode, please use the following steps:

• Exit NinjaTrader.
• Hold the CONTROL key and double click the NinjaTrader icon.
• Keep the CONTROL key held down until you see the Control Center.
• You can verify you are in safe mode by going to Help -> About.

After testing in Safe Mode, please return to normal operation mode. Do not open your workspace. Instead try to recreate it from scratch without using any templates. You may do this 1 chart at a time, and I suggest to start with the most complex charts first.

If you see an error arise when building a chart, we know that it cannot be a corrupt workspace issue, and we will then have to troubleshoot our indicators. If we don't see an error and have successfully rebuilt the workspace, we know that the issue was with the workspace and you will have a new workspace to use in its place. Please save a back up of this workspace as well as your platform to prevent setbacks from these issues in the future.

If you did see an error and have to troubleshoot the indicators, you will then have to rebuild the chart one indicator at a time while testing with the addition of each indicator. Once the issue is found, please notify the indicator developer of the issue and the steps you have taken.

If you are able to reproduce this issue in a consistent fashion that shows an internal issue with NinjaTrader, please let us know and give us exact steps that we can take to reproduce the matter. We can then forward the issue to the development team for a general solution.

Please let me know if I may be of further assistance.

[JerryWar]

Jim thank you for your reply I am sure your sincere in your efforts, but they are off target.
1) The workspace and ninjaTrader will always start up with no problems immediately after the error occurs. I have never seen it not. So starting in safe mode proves / solves absolutely nothing. Why go thru rebuilding the workspace and testing one indicator at a time etc. How do I test? I had two crashes today because of this error. So lets estimate it takes 4 hours of running to recreate the problems, So lets see thats 4 hours of running on each and every indicator I need to add. So a week from now I will have loaded and run every combination of indicators. It still would of told me nothing. I rebuilt my charts two days ago , ran for a day and now today 2 crashes. So you cannot debug and issue like this as you suggest.
2) I do not use OnRender and the issue is caused by a Line if your error is correct. I only use draw.Line in one routine. I have put every conceivable check on each and every variable before calling Draw.Line and Nothing trigger and I still got the error.

3) Further I had an issue over 6 months ago with Draw.text. when using multiple data series on the chart. It took months of testing and finally I was able to prove it to support such that they could replicate it . Now after many new versions it still isn't fixed. I know because I checked and tested it the other day. So I can go thru the same B.S. with this line exception and even if I prove it is your problem It gets me no where fast. I can't spend my day watching the market and debugging your issues. My business decision is to go back to NT7.

[NinjaTrader_Jim]

Hello JerryWar,

I understand the frustration.

I have tried to reproduce this issue in another thread using a basic indicator that I have created that draws lines, but I was not able to reproduce the issue.

Could you provide me a bare-bones indicator that you know reproduces this issue?

Is testing for numerous hours the only way to reproduce?

Please understand that to effectively fix issues, we need to consistently reproduce them. This is where we try to steer away from lengthy test cases. However, if this is the only way to consistently reproduce the issue, we must do this.

If the Draw.Text issue is still actual and you are curious on the status, you may bump the thread or write in to platformsupport[at]ninjatrader[dot]com to request a status updated on the issue's ticket ID.

I look forward to looking into this matter further.

[soulfx]

Hello I concur with Jerry and his points - and have been in communication with some other frustrated users, one in particular who is very experienced and knows what he is doing. This approach to testing has its merits at times .. but the recreate workspace over and over and 1 indicator at a time i dont believe applies in this case. Likewise i have also recreated workspaces last days and it will run all day even through CL inventory report and decide to crash and hang after running for 7 hours - it is bizarre and inconsistent and random and not easy to reproduce. I have informed support of my thoughts and the need for exact steps frankly is ridiculous and out of context for certain errors and i have informed support of this to. I cannot tell the days and hours lost on this and testing over and over - to be repeated the ninja mantra of your cut and paste in your post i'm sorry it is not helpful. It would help users to know what internal testing is being done to resolve this beyond what testing we can do ; but it appears the custom developers get the blame until we can prove otherwise which in these instances with very poor error logging to note (which i have asked as have other to improve context) and again this gets brushed aside.

again look forward to this error being resolved very soon

[NinjaTrader_Jim]

Hello soulfx,

Yes, it is general practice to rule out issues from code that we have not made or makes tracking the issue more complex. Since we are a small staff we are limited to moving forward by this process. This is not intended to blame our vendors or custom developers.

As I have mentioned, I am willing to test an example for an extended period of time to look into the matter further. I have attempted to reproduce a test case for this in the past, but was not successful in reproducing the issue.

I will need assistance from you guys to reproduce this matter and get the development team involved.

In regards to the improved error logging, do you know if another technician has submitted a feature request to track this idea?

Please let me know how I may assist you further.

[JerryWar]

Jim
Understand it took a day and a half for the first error after rebuilding workspace. It seems these errors corrupt the workspaces in unknown ways at least from my view because after the first error the second error seems to follow in quicker fashion.
For this reason I cannot provide you a barebones indicator that " I know " reproduces the problem. I don't know what the problem really is. I would have to guess and write code and spend hours testing. I don't get paid for that. As an example referring back to the draw.Text issue It was never the DrawText commands like the error said it was the interference with multiple data series on the chart and the Draw.Text commands. Removing the extra data series from the chart and only adding them inside the indicator solved the problem but it meant a lot of extra cpu overhead for my indicators. I suspect the draw.line issue is similar. I just don't know at this point what the other half of the equation is.

[JerryWar]

Soulfx,
Are you using multiple data series in your indicators or the indicator you suspect is the issue ?

Thanks,
Jerry

[soulfx]

Hello, in my case i am not using multi series in my indicators - i have considered in the future but until this is resolved for One primary series i will not venture that route. I recall jessica logged this in another forum post after several requests but have not heard of any update ; you may check the forum to see which tracking id if any was allocated.

[JerryWar]

Are you using Draw.Line in your indicators for anything ?

[soulfx]

Yes i do inOnRender() - other lines are handled by indicator with the AddPlot and i have one with AddLine which is used for a Zero plot ... never been an issue - so not thought to question those.

Is interesting and confirming that you DO NOT use onRender() and emphasised that - yet are still experiencing the problem ...

And what concerns me is what Jim wrote ...

The second scenario involves a corrupt chart/workspace/template in which, for example, an abrupt shut down of the platform has damaged the files that store the information to recreate these charts.

....

given this error we and they dont know how it is triggered causes the crash and system to hang .. there is no opportunity to save the workspace for a clean graceful exit ... so the corrupt workspace scenario is a bit out of context and what does that achieve ...? you are stuck in an endless loop to no where.
I asked this question which took many times to ask before answered - when one is forced to kill the N8 process to restart for any reason it happens to lock or hang for a user - it 'can' corrupt the workspace was the answer given - so there you go on that one.

I am doing another sweep of my code later this weekend before next week to double check over use of brushes etc - but i have already done this about 6-8 times and checked the onrender best practices - and still ... so lets see what next week brings;

For the time being i also removed all drawing tools ie horizontal lines and fibs - given lines are a key component of any chart .... whether it is custom indicators or drawing tools or core ninja drawing that is the debate and investigation that is still ongoing - i have a question on a couple of things in the ninja drawing tools but i need to check a few things before writing in.

[JerryWar]

Soulfx,
Regarding Jim's comments about the workspace, I have rebuilt my workspaces over the last 6 months non-stop. Once I rebuild a workspace it seems I will have a pause in the occurrence of these type of issues. Once I have an issue if I don't rebuild the workspace the frequency goes way up. I see the issue of Ninja locking up because of the errors, further corrupts the workspace causing more issues.
This isn't the only issue I am seeing. I randomly get a Set.State error when changing an indicator value or DataSeries value when the U.I causes the code to reset. I have no clue what is causing it.

Update: after working all day with a new Workspace. I get the following after adjusting the days back of the Root Data Series on the Chart.

2017-04-29 15:04:38:716 ERROR: Indicator 'TrpScrnVollbl': Error on calling 'SetState' method: Object reference not set to an instance of an object.
If I now Reload NinjaScript The indicator that it says was in Error, loads fine with all the rest.

Now I have to rebuild the workspaces again.

[soulfx]

I hear you on the workspace rebuilds - ongoing since beta ; sigh

Reading other forum discussions it is a common issue - interestingly reluctantly accepted as part of using ninja - i have tried to devise a more efficient way to do so with chart templates.
Not sure if chart templates also can potentially be corrupted and those need to be rebuilt also ; this part doesnt seem to be mentioned as much. Are you resusing existing chart templates in your new workspace or are you indeed starting from scratch? It was also mentioned that changing indicator parameters between sessions and saving can cause issues. I plan to rebuild a workspace tomorrow and will try and not change any parameters and see what unfolds next week

[NinjaTrader_Jim]

Hello soulfx and JerryWar,

I am still monitoring this thread for any advancements in how we can reproduce the issue.

If we can utilize a sample that we know will create this issue, we can use this to present steps to reproduce for the development team. Even if it takes a very long time to reproduce the issue, it can still be used if can consistently reproduce the OnRender() errors.

I have seen these corruption issues take hold of a chart template. We will not always be able use templates to rebuild the charts cleanly. That being said, I would not advise against using these in your troubleshooting steps. Instead, I would suggest to have backup workspaces and templates that you could load onto the platform to test if your current templates and workspaces have a corruption issue. You will then be able to confirm corruption issues without rebuilding the entire workspace every time.

We perform a troubleshooting step with some clients where we have two instances of the platform to make it easier to diagnose certain issues. You may wish to use these steps to verify a sample indicator does create the issue without having to troubleshoot your workspace.

To create another instance of the NinjaTrader platform, please close NinjaTrader and rename the respective documents folder to something other than the platform folder name.

For example, for NinjaTrader 8, rename the Documents/NinjaTrader 8 folder to "NinjaTrader 8 OLD." Next, uninstall and reinstall NinjaTrader 8. You will now have 2 platform folders. 1) "NinjaTrader 8 OLD" and 2) "NinjaTrader 8"

NinjaTrader 8 will always try to load the "NinjaTrader 8" folder. To switch platforms, you can close NinjaTrader and rename the platform folder you wish to load to "NinjaTrader 8." (You will have to rename the other platform folder to something like "NinjaTrader 8 NEW.") Please keep the new instance of the platform as clean as possible to ensure clean tests with the sample indicator.

@soulfx, I could not find the feature request for the improved error logging. I will check again tomorrow during our office hours.

Please let me know if I may be be of further assistance to reproduce this matter and forward the issue to our development team.