Originally Posted by sirinsidiator
Careful. If what you want is exactly the name of the NPC (e.g. for data collection) you should definitely use the underlying API method GetUnitName in order to obtain that information, otherwise you can easily run into compatibility issues with other addons that change the formatting of the displayed name for example. On the other hand if you just want to mirror the control so the name is shown in a second place, you'd better use GetText instead, because then you automatically have the same changes from other addons applied without them needing to know about your addons functionality.
Aside from that you should be aware that GetText, classes and controls are not Lua language concepts. They are entirely ZOS' way of doing things in the UI.
|
Ah, yes. I should have said something more like "ESO's API design philosophy while opting for generic code reusability"; you're completely right, though, in sentiment and syntax. And honestly, in the OP's use case, GetUnitName() is seemingly the better approach.
Originally Posted by sirinsidiator
Never even think about doing that! Changing the EsoStrings tables directly like that is a very bad idea and calls for all kinds of trouble. It could easily break other addons.
|
Hence, I admitted the OP would need to check for whether or not the string had edge dashes, instead of just (for example) local name = ZO_InteractWindowTargetAreaTitle:GetText(); name = string.sub(name, 2, #name-2) etc, and didn't advise using EsoString changes for this situation.
As for never using EsoStrings, well the entire premise of my own addon is to alter the contents of ZO_InteractWindowTargetAreaTitle (and the other two text areas) for every single chatter interaction in substantial ways, and by necessity has to break any other addons trying to alter the same things. It does lend more weight to the merits of using GetUnitName() over GetText(), at least for anyone reading the names who doesn't want to check the data first; but, that would also reduce compatibility in some cases, if for example, the name is show somewhere new during dialog and now is missing the custom fonts and colors. But since I reset everything to default states when chatter interactions are ending, it really only can conflict in the space where my addon has to win.
So, I've got to agree to disagree on that final point about
never thinking about using EsoStrings. We agree that usually it's a bad idea, and that addons should always be working inside their own local scope as much as possible.
Edit: If it wasn't clear, I wasn't arguing that using EsoStrings is the best method or even that it should be used; I was proposing that there are cases where it would make sense, and so
never is too strong of a qualifier.