View Single Post
04/17/18, 09:31 AM
Join Date: Jan 2016
Originally Posted by
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.
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
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
is too strong of a qualifier.
Actually, for that you can hook the SetText function rather than changing EDOStrings
View Public Profile
Send a private message to Dolgubon
Find More Posts by Dolgubon