DrawText with indicator-based input

[arbuthnot]

Hi guys

I've made an indicator that works fine with Overlay = false.

What I'd like - if this is possible - is to get the values produced by the indicator written as text on the chart itself.

I've looked up 'DrawText' in Help, set Overlay = true, and have tried this:

DrawText("My text" + CurrentBar, "[B]w[/B]", 0, High[0] + 20, Color.Black);

Obviously, where I've put the "w" is where I'd like the indicator values written.

Another problem is that the chart scale goes from zero to the value (about 14,000) and so the candles are squeezed up at the top.

I'm beginning to doubt this is actually doable but any pointers will be much appreciated.

[NinjaTrader_ChelseaB]

Hello arbuthnot,
Thank you for your note.

DrawText("My text" + CurrentBar, "w", 0, High[0] + 20, Color.Black);

The line you have written will place a "w" at the high of the bar being calculated plus $20.

If you would like it to plot 20 ticks above the bar being calculated you would use High[0] + 2 * TickSize.

For example:

DrawText("My text" + CurrentBar, "w", 0, High[0] + 20 * TickSize, Color.Black);



Please let me know if I can be of further assistance with this.

[arbuthnot]

Thanks very much, Chelsea, for getting back to me on this.

It's very useful to know how the 'TickSize' code will transform the huge leap of $20 (double or more the value of some stocks) to 20 ticks - which is exactly what I want!

As you didn't refer to it, I'm guessing that there's no way of getting indicator values to be included in DrawText.

To be more precise, what I meant by this is: say the RSI value is 65. It would be nice to be able to get the '65' to be 'written' or 'drawn' on the chart (20 ticks above the high!), but I guess this is asking too much of the system!

[NinjaTrader_Matthew]

Hello,

You can store the RSI value in a double, and then convert that to a string.

double myRSI = RSI(14, 3)[0];

DrawText("My text" + CurrentBar, myRSI.ToString(), 0, High[0] + 20 * TickSize, Color.Black);

[arbuthnot]

That's really great, Matthew. Thanks. Exactly what I've been looking for for some time.

Just to add, for anyone else reading this thread, that the double values as in

double myRSI = RSI(14, 3)[0];

as they're represented numerically on the chart by this method, have 12 decimal places, which is a level of precision way beyond any trader's visual needs. (I guess it's C#'s internal floating point accuracy.)

Mostly, you just need the nearest integer, so may I suggest using the Math.Round method in C# to achieve this. So I've changed my declaration in OnBarUpdate to the following:

double myRSI = Math.Round(RSI(14, 3)[0]);

This works and gives integer values on the chart.

[koganam]

That's really great, Matthew. Thanks. Exactly what I've been looking for for some time.

Just to add, for anyone else reading this thread, that the double values as in

double myRSI = RSI(14, 3)[0];

as they're represented numerically on the chart by this method, have 12 decimal places, which is a level of precision way beyond any trader's visual needs. (I guess it's C#'s internal floating point accuracy.)

Mostly, you just need the nearest integer, so may I suggest using the Math.Round method in C# to achieve this. So I've changed my declaration in OnBarUpdate to the following:

double myRSI = Math.Round(RSI(14, 3)[0]);

This works and gives integer values on the chart.

Math.Round() is an expensive operation CPU-wise. If you really just want the integer part, it is better to cast the value thus:

double myRSI = (int)RSI(14, 3)[0];

However, I just Round2TickSize() all price-based indicator values, as that is the only thing that makes sense; we can never trade at any value other than a valid TickSize, so there is no point in getting information to a greater precision.

[arbuthnot]

Math.Round() is an expensive operation CPU-wise. If you really just want the integer part, it is better to cast the value thus:

Code:
double myRSI = (int)RSI(14, 3)[0];
However, I just Round2TickSize() all price-based indicator values, as that is the only thing that makes sense; we can never trade at any value other than a valid TickSize, so there is no point in getting information to a greater precision.

Thanks so much for this information, as many times before, Koganam.

I had no idea that Math.Round was so processor hungry. If it works much as the Round operation does in Excel, as I'm sure it does, then I can understand the why this is.

Neither had I any idea of the existence of Round2TickSize. Again to draw a parallel with Excel, which wastes most of its computational energy calculating to 15 place floating-point accuracy, when confining it to 4 place accuracy (to avoid rounding errors) will almost never cost any 2 place accuracy whatsoever, which is what most people only ever need.

You've done me a huge favour here, Koganam! I should be able to implement a few tweeks using Round2TickSize which should speed things up no end.

Much obliged.