???

hLegend = legend();
hLegend.Title.String = 'My Legend Title'.

@Yair – Yes, I’d say this is related. Obviously, there is internal support for data types for both properties and function/method arguments. But only the former got the (undocumented) @-syntax in the MATLAB language, as described by your linked post. The latter seems to be reserved to built-in functions and methods of built-in classes, that are implemented in C++ and are thus not restricted by what is exposed to the MATLAB language. (I also tried and failed to find a syntax that would work for arguments.)

I wonder why MathWorks decided to expose only “half” of this data type feature to MATLAB programmers. And I wonder why they added “full” support for querying this information directly from MATLAB in R2015a. (Not that I’m complaining, it provides interesting insights.)

Finally, I wonder what those data types really are. (I think we had something similar in the UDD class system.) They are not real classes, as can be seen in many instances in HG2. But classes can be used as data types. Will data types be fully exposed to the MATLAB language? Will we be able to create and use custom data types in the future?

@Martin – thanks, interesting. I have a hunch that this is related to the undocumented mechanism of setting class-property types using the so-called “@-filter”:

properties
    Name@char = 'abc'
    Width@double = 10
end

Unfortunately, I tried this @-filter on method input/output args and it croacks. So either it’s not implemented yet, or MathWorks may have changed the syntax, or maybe I’m just misreading the situation…

@Yair – thanks for improving my comment and fixing the minor error I included! I see you read those comments very carefully. 🙂

R2015a made it easier to to explore HG2 (and the many undocumented properties/methods of the related classes) by adding the new (and hidden) Type property to the meta.property class and the InputTypes and OutputTypes properties to the the meta.method class. For example:

mc = ?matlab.graphics.axis.Axes;
mc.PropertyList(1).Name % Camera
mc.PropertyList(1).Type % matlab.graphics.axis.camera.Camera
mc.MethodList(49).Name % addlistener
mc.MethodList(49).InputNames % [sources, propertyname, eventname, callback]
mc.MethodList(49).InputTypes % [handle, asciiString, char vector, function_handle scalar]

Knowing the type of a property can be especially helpful to find out what can be assigned to it. Sometimes one even gets a list of valid values (e.g. the CameraMode property of the above Axes class).

Interesting as always – Adding a legend title is one of the functions in my GUI Toolbox and I uploaded this particular code as a FEX submission which covers HG1 & HG2.

@Martin – Nice solution! 🙂

@Martin – thanks! this is indeed more elegant. I tried setting a text object’s Parent directly to the legend and received an error (“Text cannot be a child of Legend”); I then tried to set the DecorationContainer’s title property and got another error (since it’s not an axes and has no such property); but I didn’t think to simply try what you did, which is a variant of my failed attempts…

I guess it shows us that we should never give up hope, maybe just take a step back and rethink about the problem.

Thanks again!

hLegend = legend(...)
hlt = text(...
    'Parent', hLegend.DecorationContainer, ...
    'String', 'Title', ...
    'HorizontalAlignment', 'center', ...
    'VerticalAlignment', 'bottom', ...
    'Position', [0.5, 1.05, 0], ...
    'Units', 'normalized');

The title appears to stay attached to the legend and the Parent property of the text object even reports the legend object as its parent:

hLegend.Location = 'southwest';  % Test the title's attachment
hlt.Parent % Returns hLegend

I tested this with R2015a. The DecorationContainer was simply the first in a rather long list of properties that sounded like it could be useful.