Overflow error when drawing multiple Rays programmatically

[koganam]

I just wrote an indicator to draw rays over successive highs and successive lows. If I limit drawing to the last rays only (one each, off highs and lows respectively), everything works right.

With only 2 days of data on the chart (any intraday timeframe), I get a very mangled display, with all panels except the price panel disappering. This is consistently reproducible. Sometimes the price bars disappear (even though they are there, as the DataBox shows their values).

The log shows no errors, but a quick check of the trace file shows that there is an overflow, told by multiple lines like this:

2011-07-20 12:33:26:297 Chart.ChartControl.OnPaint: Overflow error.
2011-07-20 12:33:26:797 Chart.ChartControl.OnPaint: Overflow error.
2011-07-20 12:33:28:297 Chart.ChartControl.OnPaint: Overflow error.
2011-07-20 12:33:29:312 Chart.ChartControl.OnPaint: Overflow error.
2011-07-20 12:33:29:797 Chart.ChartControl.OnPaint: Overflow error.
2011-07-20 12:33:31:312 Chart.ChartControl.OnPaint: Overflow error.
2011-07-20 12:33:32:297 Chart.ChartControl.OnPaint: Overflow error.
2011-07-20 12:33:32:828 Chart.ChartControl.OnPaint: Overflow error.
2011-07-20 12:33:33:328 Chart.ChartControl.OnPaint: Overflow error.

There are a whole lot more. I just showed a few lines so as to show what they look like.

Is this by design?

[NinjaTrader_Austin]

koganam, I do not believe this is by design. Can you please post the script you use to generate these rays so I can test this out?

[koganam]

koganam, I do not believe this is by design. Can you please post the script you use to generate these rays so I can test this out?

Austin, while I am usually very willing to share my code, this time I would rather not publicly share this right now. Is it OK if I send you the code directly? Of course, if it is a bug, I would want you to share the code with any of your internal folks who need to see the code, in order to correct the problem.

Once I send you the code, the posted pictures pretty much provide all the information needed to replicate the issue.

Thanks.

[NinjaTrader_Austin]

Yes, that'll work out just fine. Please send it to support at ninjatrader dot com with 'Attn: Austin - ticket 517901' in the subject line. Thank you.

[koganam]

Yes, that'll work out just fine. Please send it to support at ninjatrader dot com with 'Attn: Austin - ticket 517901' in the subject line. Thank you.

Just sent you the source code.

Thanks again.

[NinjaTrader_RyanM1]

Thanks, koganam. Gave the script a run here and can see the same thing. I could work around the OHLC display issue by manually adjusting z order.

You're running into a limit on number of objects drawn. Unfortunately I don't have the exact limit # handy but will need to reduce this to the most recent 20 or so objects.

[koganam]

Thanks, koganam. Gave the script a run here and can see the same thing. I could work around the OHLC display issue by manually adjusting z order.

You're running into a limit on number of objects drawn. Unfortunately I don't have the exact limit # handy but will need to reduce this to the most recent 20 or so objects.

Well, if it is a limit, there is little that can really be done, other than maybe to start to display a warning on charts that there are too many DrawObjects?

I am reasonably certain that the limit is way above 20, because I have charts that draw many more than that. It will be necessary for us to know what that limit is: it must be somewhere in the design or technical spec document for the product. At least that way I can know what size to make my ArrayList to store the data for the DrawObjects, so that I know which one to remove. I would much rather not try to use trial and error binary search methods to try to determine a reasonable facsimile of the limits.

When was this limit introduced? I find it rather strange because my original Heiken-Ashi indicator (available in the forum) redrew EVERY candle with 3 DrawObjects (upper wick, body, lower wick), meaning that there were 3 times as many DrawObjects as candles, and we never saw this problem. The number of rays is very definitely fewer than the number of candles.

Further if this limit does exist, then we should see the same thing regardless the object being drawn. So, are we saying that if I draw Dots or Arrows, instead of Rays, we would see the same problem? Either of us could quickly modify the script to see if this is true.

[koganam]

Thanks, koganam. Gave the script a run here and can see the same thing. I could work around the OHLC display issue by manually adjusting z order.

You're running into a limit on number of objects drawn. Unfortunately I don't have the exact limit # handy but will need to reduce this to the most recent 20 or so objects.

Actually Ryan, it was even simpler to test this than I thought, and it means unfortunately that your statement as to the cause of the problem cannot be correct.

By loading ONE day on a 90 minute time frame, I can manually count the lines. There are exactly 10 lines on the chart, and it still shows the problem.

By making the chart period 100 minutes, there are now only THREE lines on the chart, and we still have the problem.

I do not mean to be snarky, but can we please not guess at what the problem might be?

[koganam]

Thanks, koganam. Gave the script a run here and can see the same thing. I could work around the OHLC display issue by manually adjusting z order.

You're running into a limit on number of objects drawn. Unfortunately I don't have the exact limit # handy but will need to reduce this to the most recent 20 or so objects.

I needed to put this to rest once and for all.

I simply changed the line that draws Rays (for the "all" case) to draw Lines instead. The result is shown in the picture: no mangling of the chart. It would appear that the problem is entirely then with drawing Rays, at least in the first instance.

To see how many drawObjects are on the chart, I used 13 days @ 1 min intervals, which is a heck of a lot of data for my trading style. By adding the line below to OnBarUpdate(), we see there are 3371 objects. After seeing that, I decided not to look for an upper limit, as that is evidently not the problem.

DrawTextFixed("DrawObjectsNumber", "Number of DrawObjects = " + DrawObjects.Count, TextPosition.BottomRight);

[koganam]

As I would expect, because ExtendedLine also apparently has no end to the line, in effect being a Ray to both sides, forward and back, DrawExtendedLine() shows the same problem as DrawRay(), where DrawLine() does not.

[NinjaTrader_RyanM1]

Great, thanks for looking into this further, Koganam. Can you please send in the latest script you're using, that shows the overflow with only a few drawn objects?

[koganam]

Great, thanks for looking into this further, Koganam. Can you please send in the latest script you're using, that shows the overflow with only a few drawn objects?

The script that shows the effects of an overflow with only 3 lines drawn is the same script that I sent before. All I did was shorten the price DataSeries to 1 day, and lengthen the chart period successively, knowing that that must necessarily draw fewer bars, and hence fewer anchor points. Using yesterday's /ES data, I used 1 day price data and 100 minutes chart period.

I am forwarding you a copy of the script, via email.

You will notice, however, that in my attempts to track down the issue, I have added in the lines to DrawLine() or DrawExtendedLine() (Both commented out). You comment out and enable as necessary for the different kind of DrawObjects.

[NinjaTrader_RyanM1]

Thanks for sending in the script. We received and will look into further.

[NinjaTrader_Brett]

Koganam,

Development looked into the code.

Here is the issue:

_dblSwingHighPrice2 is set to double.MinValue on indicator initialization and never changed, thus throws off internal painting logic.

As a test I changed out all your double.MinValues for simply 0.0 and the script worked without issue.

-Brett

[koganam]

Koganam,

Development looked into the code.

Here is the issue:

_dblSwingHighPrice2 is set to double.MinValue on indicator initialization and never changed, thus throws off internal painting logic.

As a test I changed out all your double.MinValues for simply 0.0 and the script worked without issue.

-Brett

Brett, first off, my deepest thanks to your entire support team. If this were the kind of support we got elsewhere, you would have some real competition.

Thanks for the reply. Actually the value does get changed, which is why we do end up drawing multiple lines, and also why drawing only the last lines has no problem, but what you have identified IS the problem; the value does not get changed quickly enough when drawing all the lines.

I only used double.MinValue because I was sure that all values after that would be higher. I guess that I must be more careful in the future. Rather than go on another debugging mission, I have just taken your suggestion and changed those values to zero: price cannot be less than zero anyway.

Now, if only I could get such responsive support from other vendors?! Well, one can wish anyway.