09/02/15, 10:26 PM | #1 |
|
Two 100012 Bugs
Chat Tab Overflow Bug:
See here for full details: Chat Window width & Tabs Short Detais: Tabs are being placed in the overflow container area when it is not necessary. The dimensions of the ZO_ChatSystem has a set width of 350 in xml and (as of 100012) the dimensions are not reset from the saved settings until after you call SharedChatContainer.LoadSettings(...). But that LoadSettings() is what (eventually) calls PerformLayout() which places tabs in the overflow area. So it thinks the controls width is still 350 because the saved setting dimensions have not been reset yet. When you pulled the SetAnchor & SetDimension code out of SharedChatContainer.LoadSettings you reversed the order the code is called in.
Warning: Spoiler
Lua Code:
Chat Container Creation Bug: See here for full details: CHAT ERROR SPAM Short Details: Attempting to create chat containers for multiple chat windows causes errors. I know its not a finished/enabled feature, but they are errors that do not go away by reloading the UI, uninstalling an addon, or reinstalling (or so I was told, see post I linked, so I guess the NumChatContainers must be saved server side). In the previous game version the CHAT_SYSTEM container.control child newWindowTab used to be defined in SharedChatSystem.xml and it was a child of ZO_ChatContainerTemplate. So when a new container was created (by the containerPool) using ZO_ChatContainerTemplate, the newWindowTab was there to grab. But newWindowTab has been moved to ChatSystem.xml and made a child of ZO_ChatWindow as of version 100012 So now when a new container is created (by the containerPool) using ZO_ChatContainerTemplate the newWindowTab child does not exist. ChatContainer:Initialize() attempts to grab the child newWindowTab (but it no longer exists for windows other than ZO_ChatWindow) and pass it to ZO_TabButton_Icon_Initialize which throws an error because self is nil (its supposed to be the container.control child newWindowTab). Therefore the container never gets created, but since the numChatContainers is saved in game code or server side reloading the ui or uninstalling an addon does not fix it. If you want to simulate this error for testing you can just call: Lua Code:
While I'm at it, I might as well throw this out there. For new chat container controls created (not ZO_ChatWindow) the game does not properly anchor container.windowContainer, causing it & the container.currentBuffer to have dimensions 0,0. Last edited by circonian : 09/03/15 at 09:47 PM. |
09/03/15, 03:59 AM | #2 |
About the chat container creation bug:
If we simulate it, how are we able to "reset" the new container afterwards? Or is the simulation not updating the server side container counter (as you guessed) and we are stuck with a new container we cannot remove? |
|
09/03/15, 07:48 AM | #3 |
Thanks for the detailed reports. We'll look into getting these fixed.
|
|
09/03/15, 09:09 PM | #4 | |
|
Lua Code:
Even though the solution (to stop the errors, not fix the problem) turned out to be quite simple, it still took me a while to track down what was causing it & find a solution. If someone accidently created that problem, then they would be stuck with the error & they would have no way of fixing it since uninstalling the addon, reloading the ui, or even reinstalling does not fix it. They would be forced to do what I did and track down the problem & find a way to fix it with code. Since I already did that I thought it was worth creating a post about it in case it happens to anyone else. Last edited by circonian : 09/03/15 at 09:41 PM. |
|
09/04/15, 01:27 AM | #5 |
|
One More Bug
While testing a new version of my ChatIt addons multiple windows feature I found one more bug.
It is possible to transfer the main (first) window tab of the primary container to another container. It is also possible to transfer every window out of the primary container which really causes problems. I do realize this sounds minor & highly unlikely...but it happened to me on accident, that's how I found it so I figure it could happen to someone else. Also since there are code checks to prevent transferring the 1st tab out of the primary container, it is obviously an unwanted feature so I thought I'de post this. While testing my addon I was attempting to transfer several tab windows to another chat container. To make this easier I moved them very close to each other. When you drag a tab window if the mouse overlaps more than one TabDropArea, both controls get monitored by function
Warning: Spoiler
Lua Code:
Since the tab drop areas are overlapping and that function uses GetUIMousePosition() both controls will pass the Contains(...) check and thus both containers get self.insertIndex set. Then when you actually drop the tab, whichever container it goes into properly gets self.insertIndex set to nil, but the other container will still have self.insertIndex set to some value (what value is irrelevant). If it dropped into the primary container and you then drag the 1st tab window from the primary container and drop it on top of the other containers TabDropArea (the other container still has self.insertIndex set so) it will transfer the tab to that container, even though it was the 1st tab window of the primary container because:
Warning: Spoiler
Lua Code:
container ~= initiator AND container:CanTakeTabDrop() will return true (because container still has self.insertIndex set to some value) then it will set tabDropContainer = container, then the TransferWindow code will run which will transfer the first tab window to the other container. Lua Code:
Last edited by circonian : 09/04/15 at 07:13 PM. |
ESOUI » Developer Discussions » General Authoring Discussion » Two 100012 Bugs |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
Linear Mode |
Switch to Hybrid Mode |
Switch to Threaded Mode |
|
|