Chat window width & tabs @patch 1.7

[Baertram]

Anyone else got several chat tabs and everytime you zone/reloadui only about 2 chat tabs are shown and the others are minimized behind this horizontal arrow? (the arrow that appears if the chat window width is too small to show all tabs).

Even if my chat window is half the screen width (1920) this will happen...

there is a known bug with the ui scaling reseting at startup and zone change.

[circonian]

By default, in xml code, the ZO_ChatSystem has a set width of 350.
They are not resetting the saved settings.width until after they call SharedChatContainer.LoadSettings(...)

function ChatContainer:LoadSettings(settings)
    SharedChatContainer.LoadSettings(self, settings)
 
    self.control:ClearAnchors()
    self.control:SetAnchor(settings.point, nil, settings.relPoint, settings.x, settings.y)
    self.control:SetDimensions(settings.width, settings.height)
end

But SharedChatContainer.LoadSettings(...), eventually, calls the SharedChatContainer:PerformLayout(), which is what blocks those tabs & puts them in the overflow container because it still thinks the desired width of the chat window is 350.

The saved settings.width need to be reset before the SharedChatContainer.LoadSettings(...) is called:

function ChatContainer:LoadSettings(settings)
    self.control:ClearAnchors()
    self.control:SetAnchor(settings.point, nil, settings.relPoint, settings.x, settings.y)
    self.control:SetDimensions(settings.width, settings.height)
    
    SharedChatContainer.LoadSettings(self, settings)
end

Just dump that in a code file & it should fix the problem. Would probably be a good addition to merlights Band-Aid

[Baertram]

Tahnks for the help. Couldn't get your code to work so far but I noticed the layout will get restored properly if I simply click the chat's right or top edge (where you could resize it).

So this code helps to restore the layout properly at a PlayerActivated event callback:

    --Fix for the chat tabs moved into overflow container, introduced with patch 1.7
    --Rebuild the chat layout for the primary container
	if CHAT_SYSTEM.primaryContainer ~= nil then
	    CHAT_SYSTEM.primaryContainer:PerformLayout()
    end

[circonian]

Originally Posted by Baertram Tahnks for the help. Couldn't get your code to work so far but I noticed the layout will get restored properly if I simply click the chat's right or top edge (where you could resize it). So this code helps to restore the layout properly at a PlayerActivated event callback: --Fix for the chat tabs moved into overflow container, introduced with patch 1.7 --Rebuild the chat layout for the primary container if CHAT_SYSTEM.primaryContainer ~= nil then CHAT_SYSTEM.primaryContainer:PerformLayout() end

Yes calling

CHAT_SYSTEM.primaryContainer:PerformLayout()

will also fix the problem as long as its done AFTER the settings.width is restored to the chat container.
And yes clicking on the edge of the chat window does also fix it because it calls, I'm at work I forget what it was called, but some drag/resizing function that forces a call to PerformLayout() for you which fixes it.

But, the code I posted did not work for you?? That is very strange, it should work, unless you have something else changing the dimensions of the chat window and messing it up again....or there is also another problem somewhere that I did not see.

• With my code, when does it mess up for you? Is it messed up on /reloadui?
• Did you try it without any other addons?

The code you posted has basically the same effect. The only difference is your letting it put the tabs in the overflow container & then fixing it. In my code I fixed it before they even get put into the overflow container area because in my code the settings.width is reset before

SharedChatContainer.LoadSettings(self, settings)

is called, which calls

CHAT_SYSTEM.primaryContainer:PerformLayout()

for you, which is why I switched them, also you can compare code from the old version and see that is how they broke it. In the previous version there was no ChatContainer:LoadSettings(settings), but instead they only called

function SharedChatContainer:LoadSettings(settings)
    self.settings = settings
 
    -- Notice this is the code from ChatContainer:LoadSettings()
    self.control:ClearAnchors()
    self.control:SetAnchor(settings.point, nil, settings.relPoint, settings.x, settings.y)
    self.control:SetDimensions(settings.width, settings.height)
    ... more code...
end

But notice they used to reset the settings.width BEFORE any other code in this function ran. They just moved the anchor & setDimensions out into its own function ChatContainer:LoadSettings() but when they did they reversed the order the code was run in which is what messed it up.

[Baertram]

Nope, I did not disable all other addons. Maybe this was the problem then.
I had tested it within an exsting addon at the player activated callback function, so it should have worked for the 1st loading and later reloaduis.

Maybe it was because of other addons (maybe pChat) which I had enabled.

For the moment the fix AFTER the chat system tabs got moved to the overflow button, is ok for me :-)
Thanks.

[circonian]

Originally Posted by Baertram Nope, I did not disable all other addons. Maybe this was the problem then. I had tested it within an exsting addon at the player activated callback function, so it should have worked for the 1st loading and later reloaduis. Maybe it was because of other addons (maybe pChat) which I had enabled. For the moment the fix AFTER the chat system tabs got moved to the overflow button, is ok for me :-) Thanks.

Ah, if you placed my code in the player activation event it would not work. It needs to be directly/globally in the code file so it overwrites the function when your code file is loaded. By player activation that function has already been run by the game so it is to late for the change to effect anything.

[Baertram]

I thought it will be "overwritten" in the player activation event too.
But if I think about it further: Right, this makes sense
I'll retest it globally in the addon's file again then.

[circonian]

Originally Posted by Baertram I thought it will be "overwritten" in the player activation event too. But if I think about it further: Right, this makes sense I'll retest it globally in the addon's file again then.

Yes it will still overwrite it from inside the player activation event, but the code that needs to be overwritten runs BEFORE the player activation event and that is the only time it runs.

So if you place it in the player activation event, it does overwrite it, but its to late. The "original" code has already been run & does not get run again until you reload the ui, but then the process starts all over again. The game uses the original code until player activation when you overwrite it again, but again its to late the code already ran...so it never actually fixes anything that way.