PineCoders

How to avoid repainting when NOT using security()

Even when your code does not use security() calls, repainting dynamics still come into play in the realtime bar. Script coders and users must understand them and, if they choose to avoid repainting, need to know how to do so. This script demonstrates three methods to avoid repainting when NOT using the security() function.

Note that repainting dynamics when not using security() usually only come into play in the realtime bar, as historical data is fixed and thus cannot cause repainting, except in situations related to stock splits or dividend adjustments.

For those who don’t want to read
Configure your alerts to trigger “Once Per Bar Close” and you’re done.

For those who want to understand
Put this indicator on a 1 minute or seconds chart with a live symbol. As price changes you will see four of this script’s MAs (all except the two orange ones) move in the realtime bar. You are seeing repainting in action. When the current realtime bar closes and becomes a historical bar, the lines on the historical bars will no longer move, as the bar’s OHLC values are fixed. Note that you may need to refresh your chart to see the correct historical OHLC values, as exchange feeds sometimes produce very slight variations between the end values of the realtime bar and those of the same bar once it becomes a historical bar.

Some traders do not use signals generated by a script but simply want to avoid seeing the lines plotted by their scripts move during the realtime bar. They are concerned with repainting of the lines.

Other traders use their scripts to evaluate conditions, which they use to either plot markers on the chart, trigger alerts, or both. They may not care about the script’s plotted lines repainting, but do not want their markers to appear/disappear on the chart, nor their alerts to trigger for a condition that becomes true during the realtime bar but is no longer true once it closes. Those traders are more concerned with repainting of signals.

For each of the three methods shown in this script’s code, comments explain if its lines, markers and alerts will repaint or not. Through the Settings/Inputs you will be able to control plotting of lines and markers corresponding to each method, as well as experiment with the option, for method 2, of disabling only the lines plotting in the realtime bar while still allowing the markers and alerts to be generated.

An unavoidable fact is that non-repainting lines, markers or alerts are always late compared to repainting ones. The good news is that how late they are will in many cases be insignificant, so that the added reliability of the information they provide will largely offset the disadvantages of waiting.

Method 1 illustrates the usual way of going about things in a script. Its gray lines and markers will always repaint but repainting of the alerts the marker conditions generate can be avoided by configuring alerts to trigger “Once Per Bar Close”. Because this gray marker repaints, you will occasionally see it appear/disappear during the realtime bar when the gray MAs cross/un-cross.
Method 2 plots the same MAs as method 1, but in green. The difference is that it delays its marker condition by one bar to ensure it does not repaint. Its lines will normally repaint but its markers will not, as they pop up after the condition has been confirmed on the bar preceding the realtime bar. Its markers appear at the beginning of the realtime bar and will never disappear. When using this method alerts can be configured to trigger “Once Per Bar” so they fire the moment the marker appears on the chart at the beginning of the realtime bar. Note that the delay incurred between methods 1 and 2 is merely the instant between the close of a realtime bar and the beginning of the next one—a delay measured in milliseconds. Method 2 also allows its lines to be hidden in the realtime bar with the corresponding option in the script’s Settings/Inputs. This will be useful to those wishing to eliminate unreliable lines from the realtime bar. Commented lines in method 2 provide for a 2b option, which is to delay the calculation of the MAs rather than the cross condition. It has the obvious inconvenient of plotting delayed MAs, but may come in handy in some situations.
Method 3 is not the best solution when using MAs because it uses the open of bars rather than their close to calculate the MAs. While this provides a way of avoiding repainting, it is not ideal in the case of MA calcs but may come in handy in other cases. The orange lines and markers of method 3 will not repaint because the value of open cannot change in the realtime bar. Because its markers do not repaint, alerts may be configured using “Once Per Bar”.

Spend some time playing with the different options and looking at how this indicator’s lines plot and behave when you refresh you chart. We hope everything you need to understand and prevent repainting when not using security() is there.
Sep 24
Release Notes: Updated comments.
Sep 24
Release Notes: Vacuumed unnecessary plotshape() parameter.
Remove from Favorite Scripts Add to Favorite Scripts
http://www.pinecoders.com — Tools and ideas for all Pine coders.
Great work!

What if you have a study that you want to print signals after the bar close? I found that this solution works.

plotshape(barstate.ishistory ? first_alert : barstate.isconfirmed ? first_alert : na, size=size.normal, title="Buy", style=shape.labelup, location=location.belowbar, color=color.green, textcolor=color.white,text="Buy")

This way, I can see my signals plot on all the historical bars and on the last tick of each realtime bar. So there is no repainting and no delays.
Reply
PineCoders Gammapips
@Gammapips, Hi, yes, that will work fine for displaying non-repainting labels. You can test on "barstate.isconfirmed" alone for the same result. If, however, you require non-repainting alerts which could be set to trigger "Once Per Bar", then an alert condition using such a construct will not work. This code will plot labels correctly, for example, but its alerts will never trigger:
//@version=4
study("")
first_alert = barstate.isconfirmed and close > open
plotshape(first_alert)
alertcondition(first_alert)
+1 Reply
Gammapips PineCoders
@PineCoders, Excellent. Your'e right "barstate.isconfirmed" works just fine by itself.

For my alertcondition I don't use any barstate statements, and just select "Once per bar close"
Reply
PineCoders Gammapips
@Gammapips, Wise man speaking )
Reply
PEACHY !
Reply
PineCoders syrinxflunki
@syrinxflunki, ) Thx. Appreciate.
Reply
On Point! Thanks LucF :)
Reply
@Ammaru, Thx for taking the time to say so.
Reply
Thanks Luc, ya da man!
Reply
Home Stock Screener Forex Screener Crypto Screener Economic Calendar Shows How It Works Chart Features Pricing House Rules Moderators Website & Broker Solutions Widgets Charting Solutions Lightweight Charting Library Help Center Refer a friend Feature Request Blog & News FAQ Wiki Twitter
Profile Profile Settings Account and Billing Refer a friend My Support Tickets Help Center Ideas Published Followers Following Private Messages Chat Sign Out