string vs "input"

[VincentSDSH]

I know this has been answered before but I can't seem to locate the answer and it's bothering me. If a user inputs color codes in an input field, the return from an input field is treated differently than a string with the same codes would be -- applies to fontstrings and chat output.

They have the same metatable as strings but they don't seem handled the same way. You can see an example below (though far from the only one I've done).

BottleOfAspirin= {
    name = "type=input color code",
    type = "input",
    width="full",
    order = 220,
    get = function() return self.BottleOfAspirin end,
    set = function(i, v) 
        self.BottleOfAsprin = v; 
            
        debug(v)
        debug(self.BottleOfAsprin)
        debug("|cffff0066"..self.BottleOfAspirin.."|r")
    end
},

I can't remember why the escape codes aren't escape codes and it's gnawing at what's left of my tiny little mind.

[semlar]

I assume your input is coming from the chat, and it's escaping your text so the literal characters get sent because it's for chat messages, not code.

This is just a function of the chat frame to sanitize input so people don't have their messages behave unexpectedly.

[myrroddin]

I'm sure you have your reasons, but not simply use type = "color"?

[VincentSDSH]

And doesn't formally reassess it in a constructor. Ok, memory slowly coming back. Thanks.

get = function() return self.BottleOfAsprin:gsub("|", "//") end,
set = function(i, v) self.BottleOfAsprin = v:gsub("//", "|") end,

In my private addons I expose the codes for readability in the entry fields (see example) so I've been inadvertently working around the behavior for years. Went to add it into one my public addons and couldn't get the question out of my head.

[VincentSDSH]

Originally Posted by myrroddin I'm sure you have your reasons, but not simply use type = "color"?

Heh, yes: user discretion interior-text color tagging (e.g. renaming "raid food" to "really expensive food")

Take Executive Assistant tasks, if I want to make a couple of related items but not fiddle with a sub-group for them.

[nix P->C] ea module call handler error (recheck)
[nix P->C] qi !Primary! Lookup table not error checking
[nix P->C] qi control availability logic bug
ilr: recheck handling similar to [nix P->C]

I, the author, don't want to fiddle with this; I, the user, bloody well want to do this. Occasionally.