Center Announce messages 'stuck' when returning to fullscreen?

[Khaibit]

So, I've had a few users comment that the center screen announce messages that my addon generates all re-appear and get stuck on-screen if you alt-tab out of the game and then alt-tab back in. I don't normally play in 'true' full-screen mode (since I tend to be alt-tabbing back and forth a lot I stay in "windowed" full-screen), so I didn't notice it during development, but...they're right. They do. :\

Is this a bug with the center screen announce object in general? Or am I doing something incorrectly here? I'm generating messages like so:

local alertSound = (user setting, read from savedvars)
CENTER_SCREEN_ANNOUNCE:AddMessage(EVENT_SKILL_RANK_UPDATE, CSA_EVENT_SMALL_TEXT, 
  alertSound, string.format("my string that actually has variables", var1, var2, ...))

On occasion more than one is queued up in rapid succession, but they display normally and disappear normally in all instances that I've seen. The message text isn't particularly complex, an item link in the middle of a sentence with no other special characters. But if I start the client in true fullscreen mode, alt-tab out, alt-tab back, and however many I've displayed since the last /reloadui all 'stack' and sit there.

[Khaibit]

Reviving this as I still haven't found a fix...are we just not "supposed" to add messages to the center screen announce object, or is there some way that I am supposed to clean up after adding a message to the CSA? Even after Update 3, I can trigger this behavior by running in full-screen (as opposed to full-screen windowed mode) and alt-tabbing out, waiting a minute or so, and alt-tabbing back in. Not every time, but a good portion of the time, every message I've added to the CSA since the last /reloadui all appear stacked on each other and don't go away until I /reloadui or relog.

I've tried using DisplayMessage as well, like so:

CENTER_SCREEN_ANNOUNCE:DisplayMessage(CSA_EVENT_SMALL_TEXT, 
  alertSound, string.format("my string that actually has variables", var1, var2, ...))

The string being sent is plain text other than a single use of the "gold coin" texture, but the issue existed before I started using that texture and the string was nothing more than plain text.

The actual string, in the event I'm doing something naughty there by accident:

local theString = "|cFFFFFFYou have sold %s x%d for |cD5B526%s |t16:16:EsoUI/Art/currency/currency_gold.dds|t |cFFFFFFfrom %s %s."
CENTER_SCREEN_ANNOUNCE:AddMessage(EVENT_SKILL_RANK_UPDATE, CSA_EVENT_SMALL_TEXT, alertSound,
                string.format(theString, zo_strformat("<<t:1>>", anItemLink), aNumberAsString, stringPrice, guiildAsString, timeSinceEventAsString))

[Seerah]

I haven't tried using CENTER_SCREEN_ANNOUNCE. I use the ZO_Alert function, which outputs messages to the upper right corner (where screenshot text and other UI messages are displayed).

[Garkin]

Originally Posted by Khaibit Reviving this as I still haven't found a fix...are we just not "supposed" to add messages to the center screen announce object, or is there some way that I am supposed to clean up after adding a message to the CSA? Even after Update 3, I can trigger this behavior by running in full-screen (as opposed to full-screen windowed mode) and alt-tabbing out, waiting a minute or so, and alt-tabbing back in. Not every time, but a good portion of the time, every message I've added to the CSA since the last /reloadui all appear stacked on each other and don't go away until I /reloadui or relog. I've tried using DisplayMessage as well, like so: CENTER_SCREEN_ANNOUNCE:DisplayMessage(CSA_EVENT_SMALL_TEXT, alertSound, string.format("my string that actually has variables", var1, var2, ...)) The string being sent is plain text other than a single use of the "gold coin" texture, but the issue existed before I started using that texture and the string was nothing more than plain text. The actual string, in the event I'm doing something naughty there by accident: local theString = "|cFFFFFFYou have sold %s x%d for |cD5B526%s |t16:16:EsoUI/Art/currency/currency_gold.dds|t |cFFFFFFfrom %s %s." CENTER_SCREEN_ANNOUNCE:AddMessage(EVENT_SKILL_RANK_UPDATE, CSA_EVENT_SMALL_TEXT, alertSound, string.format(theString, zo_strformat("<<t:1>>", anItemLink), aNumberAsString, stringPrice, guiildAsString, timeSinceEventAsString))

I have made some testing and it seems that DisplayMessage method can easily break CSA. With or even without using Alt-Tab.

I have sent a lots of messages in a short period of time to CSA and results are:
CENTER_SCREEN_ANNOUNCE.m_displayMode = 0 (this means that CSA is inactive)
CENTER_SCREEN_ANNOUNCE.m_activeLineCount = 40 (40 acitve lines? WTF?)
CENTER_SCREEN_ANNOUNCE.m_activeSmallTextLines = table with 3 controls which are stuck on the screen

After next Alt-Tab:
CENTER_SCREEN_ANNOUNCE.m_displayMode = 0
CENTER_SCREEN_ANNOUNCE.m_activeLineCount = -40 (negative count?)
CENTER_SCREEN_ANNOUNCE.m_activeSmallTextLines = empty table

After next Alt-Tab:
CENTER_SCREEN_ANNOUNCE.m_displayMode = 1 (1 = CSA_EVENT_SMALL_TEXT)
CENTER_SCREEN_ANNOUNCE.m_activeLineCount = -188 (even more interesting, how did I get this number?)

And at this point is CSA completely broken, because m_displayMode is not 0, CENTER_SCREEN_ANNOUNCE:CanDisplayMessage() returns false, so no new messages will be displayed.

So I recommend using AddMessage instead. It will add messages to queue and should not break CSA.
as for the AddMessage:

CENTER_SCREEN_ANNOUNCE:AddMessage(eventId, category, sound, message, combinedMessage, icon, iconBG, expiringCallback, barParams)

eventId: identifier used as key in the table, it does not have to be actual event. If this key wasn't registered by ZO_CenterScreenAnnounce_SetEventPriority(eventId), it will automatically get lowest priority, so if there is more messages at the same time, your message will be displayed last. If you want to be at the top of priority list, just register your eventId using the mentioned command (ZO_CenterScreenAnnounce_SetEventPriority("MyEventID"))
category:
CSA_EVENT_SMALL_TEXT = 1
CSA_EVENT_LARGE_TEXT = 2
CSA_EVENT_COMBINED_TEXT = 3
CSA_EVENT_NO_TEXT = 4
sound: (nilable) string, sounds are defined in global table SOUNDS
message: (nilable) string, message to display
combinedMessage: (nilable) string, if category is CSA_EVENT_COMBINED_TEXT this messagege will be displayed as a small text
icon: (nilable) string, texture file path, works only for CSA_EVENT_COMBINED_TEXT
iconBG: (nilable) string, texture file path, background for icon defined above, works only for CSA_EVENT_COMBINED_TEXT
expiringCallback: (nilable) function which will be run when fade out animation is finished
barParams: (nilable) table, or more like object created by CENTER_SCREEN_ANNOUNCE:CreateBarParams(barType, startLevel, start, stop, sound). As this is used for PLAYER_PROGRESS_BAR, you will probably never use this argument.

[Khaibit]

Thanks Garkin, see my second code block there for how I'm currently doing it (using AddMessage as you suggest); I only mention DisplayMessage as I tried using it to see if it made any difference in terms of the alt-tab 'bug' (and I'll be reverting it in a bugfix release to Shopkeeper this weekend as I don't like how DisplayMessage floods the screen anyway).

Maybe it's because I'm re-using an existing event type (EVENT_SKILL_RANK_UPDATE) rather than registering my own? I'll have to experiment with that, as well as checking the activeLineNumber value even though I'm currently using AddMessage.

Curiouser and curiouser...

[Khaibit]

So, just because I hate it when I find stuff with Google later that never ends in an actual solution...I figured out what was causing this behavior. Apparently, leading off with a color code at the front of the string you're sending to the announce object will cause it to bug out and get 'stuck' when alt-tabbing back and forth out of the client.

It's the damndest things...