Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
Warning about setting properties of Plots outside of Initialize()
Plots are defined within the Initialize() method. However, some of us have been setting the properties of Plot objects in OnStartUp() and in OnBarUpdate().
There's nothing wrong with doing that, but the code must prevent a possible problem. If the indicator is being used by another indicator instead of being invoked directly, the indicator will not be plotted to a chart, there will be no ChartControl object for that indicator, and those Plot objects will not exist.
Trying to set the propery of an object that does not exist will cause a Null Reference Exception that will probably KO the program, even if there is an error handler to trap the exception.
There is an easy way to avoid this problem. Whenever doing anything outside of the Initialize() block with a Plot related property such as Pen.Width, Pen. DashStyle, Width, etc do all of those operations within a code block that only executes IF THE CHARTCONTROL OBJECT IS NOT NULL.
@Zondor: Thank you for bringing up this subject. However, I have not seen this as a problem so far. To make my position clear, I would like to make a distinction between two different cases.
(1) Use of ChartControl
There is a number of indicators that make use of ChartControl either in OnStartUp() or in OnBarUpdate(), and it is clear that this will causes a problem if
-> there has been no null reference check for ChartControl
-> when that indicator is called by another indicator or strategy
For example, all my recent paint bar indicator, use a different way of coloring bars for candle sticks as opposed to OHLC bars, and I have therefore introduced a null reference check before I use ChartControl to identify the chart style, see code below
However, I have never had any problem by accessing properties of the plots in OnStartUp() or OnBarUpdate(), even if there was no chart. For me a Plot is a Dataseries object to which a few numeric properties have been added and which even exists, if there is no chart and ChartControl takes the value null.
I access Plot in nearly all my indicators, and there has never been any problem in accessing the properties of a plot. This is quite different from ChartControl, where had to change the code of some indicators, which I had coded a few years ago.
I never thought case 2 was a problem either, but I was getting NullReferenceException errors with one particular indicator that was being called by other indicators, where inserting the ChartControl condition solved the problem.
It might have had something to do with that particular indicator. However, in general, inserting that condition is, at worst, harmless.
I never thought case 2 was a problem either, but I was getting NullReferenceException errors with one particular indicator that was being called by other indicators, where inserting the ChartControl condition solved the problem.
It might have had something to do with that particular indicator. However, in general, inserting that condition is, at worst, harmless.
Maybe I was not clear, I think that your example, setting plot properties, does not require a prior checking of ChartControl for null.
I only had to do that checking for a null reference, when I actually called ChartControl itself in the OnStartUp() or OnBarUpdate() sections. Some of my early indicators, including one of the first versions of the SuperTrend was not well-behaved for that reason....