Increasing the line width of box plot whiskers (2024)

findobj('Tag','boxplot') finds all* objects whose Tag is 'boxplot'. This includes any object whose Tag is 'boxplot' anywhere in the current figure as well as in other figures created previously. Therefore, assuming that initially there are no objects whose Tag is 'boxplot', after the first boxplot is created here, findobj finds one object. Then, after the second boxplot is created, findobj finds both boxplots. In subsequent runs, assuming the figure hasn't been closed, findobj finds all existing boxplots.

The problem is, when there is more than one boxplot found, the returned value from findobj is a non-scalar array, on which dot indexing (as in the syntax "bx2.Children") produces a non-scalar comma-separated list, so

is the same as saying

when bx2 is an array of two objects. The set function doesn't know what to do when you give it an object as each of the first two inputs. That's what the error message is complaining about.

One way to avoid this problem is to constrain findobj only to find the boxplot you're interested in modifying. In this case, you can use findobj(gca,'Tag','boxplot') to find only objects in the current axes whose Tag is 'boxplot', and that should work fine.

Another approach would be to use the (undocumented) return value from the boxplot() function, which is the lines created by the boxplot() function. These are equivalent to the Children of the boxplot group object, so

is equivalent (in this case) to

Here I'll use each approach one time:

*Actually, it finds all objects whose HandleVisibility is 'on' and whose Tag is 'boxplot'.

should work ok; the problem is the outliers are also line objects which may be different sizes. The above returns the handles only for the other lines. If you also want the outlier markers heavier, you need to retrieve those handles separately and either loop or use the expanded version of set() with cell arguments to handle the different data by handle.

Without your specific data we can't duplicate exact code here.

I'd recommend considering the alternate boxchart if you want to modify things; it exposes most of the properties without the grief of having to search for them. Why on earth Mathworks thought hiding stuff inside boxplot was a good idea simply boggles the mind, though...although that goes for all the specialized plots; just some are more egregious than others.