I use this quite a lot as per C# standard of using public properties instead of fields for classes. I would like for the summary to be visible in this use case as well.
I would add to it the addition of specifying a field. That way you can do:
[SerializeField][TooltipSummary("F")] private float f; // Displays "F is used to do super cool stuff!" in the inspector.
/// <summary>F is used to do super cool stuff!</summary>
public float F
{
get => _f;
set
{
_f = value;
DoSuperCoolStuff();
}
}
Tooltip attributes work with SerializedProperty, not with fields. Your field is automatically serialized in your first example because it’s declared as public and belongs to a class which derives from MonoBehaviour.
Unity does not serialize C# properties, whether they’re automatic or not. You cannot use SerializeField attribute on properties. (edit3: btw that attribute applies to your next field _lookPitch, so that’s why it works)
When you make a custom editor/inspector, you get full access to how inspector works, and you may introduce tooltips even for random stuff like pieces of graphic and non-interactable UI elements, if you wanted.
The documentation is lousy (for the most part) and you need a lot of practice to get the hang of it. Especially SerializedObject and SerializationProperty can be tricky if you’re new to this.
edit:
It’s worth noting that fields do not have to be public to be serialized, but then you must use SerializeField to instruct Unity this should be the case.
Similarly if you don’t want a public field to be automatically serialized, you use NonSerialized attribute.
Finally if you want your field serialized but hidden in the (automatic) inspector, you can use HideInInspector.
edit2:
Oh btw, serialized “property” is a misnomer. They have nothing to do with C# properties. It’s part of the serialization API where any value that is accessible by the inspector is simply referred to as ‘property’ in plain human language.
You don’t need to mention serialization to get a serialization-related answer. I don’t get this part of your reply.
You are using a Unity attribute in a serialization context. Whether you are aware of it or not, is something else.
If you’re talking about Unity I gave you explanation why exactly that works, but no, Unity does not serialize properties. And it’s been like this for ages, pretty much we all know these rules better than we know our parents.
I’m not sure where the responsibility lies there then, either with Unity or whoever does the Visual Studio integration.
I honestly didn’t know that was a thing at all. I always just use /// <summary> as it’s more native, and I can include references to class definitions that I can click on and navigate to them.
Rider has the same feature of showing [Tooltip] in the hover-tooltip, and the same bug of now showing it when targeting fields.
Working:
Not working:
Pretty sure the reason why it’s like that is because you’re not hovering the thing that’s got the tooltip, so for this to work you’d need a special case for properties to look for backing fields.
This feature request for sure belongs in Code Editors & IDEs. @John_MSFT is the Microsoft employee around there, while @van800 is the Jetbrains guy around here.
Though I mean this is a pretty esoteric use of a minor, esoteric feature, so it’ll probably not shoot up to the top of any issue trackers.
That’s a good point, I’m a bit late to the party where “documenting my code” is concerned but yeah after some DIY it’s easy to see how powerful xml comments can be.
My efforts are now focused on doing it the other way around, writing some [TooltipXml] attribute that transforms xml comments into a tooltip. I tried to do this using reflection however for this I need to generate the .xml files but I’m having some trouble. I understand I need to go under the .csproj > Properties > Build > Output and check “Xml documentation file”, but whenever I try to go under Properties VS just kinda… blinks, and the Properties window never pops up. Anyone else having this issue?
Alternatively, I can write my comments in separate .xml files and use in my code, and for the tooltip retrieve it from that separate file instead. Since I usually only document packaged code that might not actually be that bad.
