Tomasz
August 22, 2019, 10:33am
6
I got this impression from this post:
ThomThom said
Speaking of Names…
The Material class has two seemingly similar methods, #name and #display_name. The documentation says that #display_name is preferred, but doesn’t explain why.
The difference is that if a material name is wrapped in square brackets, like “[MyMayerial]”, then #name will return “[MyMayerial]” and display_name will return “MyMayerial”. The latter is how SketchUp will display the material name in the UI, while #name returns the real name.
If you refer to a mater…
which contains an excerpt from your blog. I didn’t notice it was from 2017 though. My bad.
Ok. I will.
opened 02:52PM - 23 Aug 19 UTC
enhancement
C API
SketchUp
logged
Live C API
parity
1. I would like to read a material name exactly the way it is displayed in Sketc… hUp in live content. Neither GetName() nor GetNameLegacyBehavior() return correct localized name for all built-in SketchUp library materials in localized versions.
To get the correct name we have to first check whether material name is enclosed in the square brackets, then go back to Ruby, find material by .name and read .display_name from it, which is slow. We can alternatively go through Materials.strings list and do the translation of [MaterialName] ourselves, but this is even more exotic.
2. A new function SUMaterialGetDisplayName() looks like a reasonable solution, at least for a live model case.
In case of standalone/external use of the SDK the function could return same string as GetNameLegacyBehavior(), if it would be a problem with supplying the Materials.strings with the SDK.