Chat message colours

[Phanx]

Originally Posted by Lombra http://wow.go-hero.net/framexml/1768...Frame.lua#2840

Originally Posted by Aanson But that points to CF_MEH which is where 'self' is coming from. I know that MessageEventHandler is passed with chat frame as it's 1st arg. Filters don't. If you check out ChatFrame_AddMessageEventFilter (event, filter) line 3193 of ChatFrame.lua, you'll see what I'm talking about.

Look again. The specific line of code Lombra linked clearly shows that self -- which in that scope is a reference to the chat frame handling the event -- is the first argument passed to every chat filter function.

The lines you mentioned handle adding new filter functions -- that part of the code has nothing to do with calling filter functions.

Originally Posted by Aanson That way I have a guarantee that the message will actually be displayed. It should be reliable because self.lastEvent will always be obtained immediately before AddMessage gets called.

That's not reliable at all. The default UI calls AddMessage from inside its OnEvent script, and HookScript is the equivalent of hooksecurefunc -- it runs your script after the original, so your event handler hook will run after the default UI has already called AddMessage, and your AddMessage hook will be seeing the previous event. In many cases (eg. Trade chat in a city) this will be the same event, but in many other cases it will not be.

[pelf]

Alright, I see the reason for both, now. I just got thrown off by the talk about "the color used by the last message" instead of just looking up the color once you have the chat type.

Incidentally, what is the chat type of a message that gets added like this?

DEFAULT_CHAT_FRAME:AddMessage("Hello, world.")

Does is it end up as "SAY", even though it isn't?

@Phanx
After ChatTypeGroup is defined, a reverse lookup table is created called ChatTypeGroupInverted. Couldn't that be used instead of the one you created in your code? The output is the key into ChatTypeInfo, so I assume it could be.

[Lombra]

Originally Posted by Aanson But that points to CF_MEH which is where 'self' is coming from. I know that MessageEventHandler is passed with chat frame as it's 1st arg. Filters don't. If you check out ChatFrame_AddMessageEventFilter (event, filter) line 3193 of ChatFrame.lua, you'll see what I'm talking about.

If you check the exact line that I linked (highlighted), you will see that self is passed to filterFunc, which is the function that you register using ChatFrame_AddMessageEventFilter. ChatFrame_AddMessageEventFilter itself doesn't take a frame because the filter is applied to all chat frames.

Edit: Didn't see new posts.

[Aanson]

Oooof.

I see your point about not getting the event until all of the ChatFrame's OnEvent code has already run. Should be easily fixed though ty.

[Aanson]

Originally Posted by pelf Alright, I see the reason for both, now. I just got thrown off by the talk about "the color used by the last message" instead of just looking up the color once you have the chat type. Incidentally, what is the chat type of a message that gets added like this? DEFAULT_CHAT_FRAME:AddMessage("Hello, world.") Does is it end up as "SAY", even though it isn't? @Phanx After ChatTypeGroup is defined, a reverse lookup table is created called ChatTypeGroupInverted. Couldn't that be used instead of the one you created in your code? The output is the key into ChatTypeInfo, so I assume it could be.

I'm not sure what it would default to actually.

I'd just assumed that Phanx had written it that way to avoid global table lookups all the time.

[Aanson]

Originally Posted by Lombra If you check the exact line that I linked (highlighted), you will see that self is passed to filterFunc, which is the function that you register using ChatFrame_AddMessageEventFilter. ChatFrame_AddMessageEventFilter itself doesn't take a frame because the filter is applied to all chat frames. Edit: Didn't see new posts.

Gotcha, sorry.

local filterFunc = function(self, event, ...)
  -- do stuff;
end
ChatFrame_AddMessageEventFilter("AN_EVENT", filterFunc);

Back to the drawing board for me, I guess.

[Phanx]

Originally Posted by pelf Incidentally, what is the chat type of a message that gets added like this? DEFAULT_CHAT_FRAME:AddMessage("Hello, world.")

It doesn't have a type. Adding a message directly does not trigger any event handlers.

Originally Posted by pelf After ChatTypeGroup is defined, a reverse lookup table is created called ChatTypeGroupInverted. Couldn't that be used instead of the one you created in your code? The output is the key into ChatTypeInfo, so I assume it could be.

Ah, I missed that. Yes, that will work.

Also, I've realized that using only a filter could "alert" on messages that aren't actually added to the frame (due to being removed by another filter). If you want to account for that possibility, you could use an AddMessage hook in conjunction with a filter, but you'd want to be a little smarter about it than just assuming the last event seen by the filter was related to the current message.

local lastGroup = {}

local ChatTypeGroupInverted = ChatTypeGroupInverted
ChatFrame_AddMessageEventFilter(function(frame, event, ...)
     lastGroup[frame] = ChatTypeGroupInverted[event]
end)

local function AddMessage(frame, message, r, g, b)
     local group = lastGroup[frame]
     lastGroup[frame] = nil
     if not group or not MONITORED_EVENTS[group] or not frame.isDocked then return end

     local color = ChatTypeInfo[group]
     if r == color.r and g == color.g and b == color.b then
          -- check group against your settings and flash if desired
     end
end

for i = 1, 10 do
     local frame = _G["ChatFrame"..i]
     hooksecurefunc(frame, "AddMessage", AddMessage)
end

Still not foolproof, but better than no checking at all. Also note that your MONITORED_EVENTS table would need to be changed to hold chat groups (eg. the keys in ChatTypeInfo) rather than all the individual events... if you actually want to let users pick and choose individual events instead of whole groups, just set event as the value in the filter, and do the ChatTypeGroupInverted lookup to find the group (to find the color) in the AddMessage hook after the return check.

[Aanson]

Originally Posted by Phanx Also, I've realized that using only a filter could "alert" on messages that aren't actually added to the frame (due to being removed by another filter). If you want to account for that possibility, you could use an AddMessage hook in conjunction with a filter, but you'd want to be a little smarter about it than just assuming the last event seen by the filter was related to the current message.

Yeah, that was my concern when I initially dealt with it via filters. My other concern was that filters are checked quite early on in CF_MEH and the message could potentially (albeit a slim chance) get filtered out later on during the function.

Thanks for that example code and for the advice Phanx. I'll get stuck into it now.