[BCC] v4.9 Upgrade install lots of localization errors
Road-block opened this issue ยท 24 comments
This is on enUS client BCC.
Upgrade over an old Classic version.
The following error shows on login.
1x BiSTracker\core\ChatCommands.lua:15: attempt to index upvalue 'L' (a nil value)
[string "@BiSTracker\core\ChatCommands.lua"]:15: in function 'InitChatCommands'
[string "@BiSTracker\core\Init.lua"]:264: in function <BiSTracker\core\Init.lua:260>
[string "=[C]:"]: ?
[string "@Accountant_Classic\Libs\AceAddon-3.0\AceAddon-3.0-13.lua"]:70: in function <...ccountant_Classic\Libs\AceAddon-3.0\AceAddon-3.0.lua:65>
[string "@Accountant_Classic\Libs\AceAddon-3.0\AceAddon-3.0-13.lua"]:498: in function 'InitializeAddon'
[string "@Accountant_Classic\Libs\AceAddon-3.0\AceAddon-3.0-13.lua"]:623: in function <...ccountant_Classic\Libs\AceAddon-3.0\AceAddon-3.0.lua:615>
and these when trying to take various actions, like using the /bistracker commands
1x BiSTracker\core\Init.lua:284: attempt to index field 'db' (a nil value)
[string "@BiSTracker\core\Init.lua"]:284: in function 'ToggleMinimapButton'
[string "@BiSTracker\core\ChatCommands.lua"]:43: in function 'ToggleMinimapButton'
[string "@BiSTracker\core\ChatCommands.lua"]:64: in function '?'
[string "@Ace3\AceConsole-3.0\AceConsole-3.0-7.lua"]:94: in function '?'
[string "@FrameXML\ChatFrame.lua"]:4825: in function <FrameXML\ChatFrame.lua:4771>
[string "=[C]:"]: in function 'ChatEdit_ParseText'
[string "@FrameXML\ChatFrame.lua"]:4488: in function <FrameXML\ChatFrame.lua:4487>
[string "=[C]:"]: in function 'ChatEdit_SendText'
[string "@FrameXML\ChatFrame.lua"]:4524: in function 'ChatEdit_OnEnterPressed'
[string "*:OnEnterPressed"]:1: in function <[string "*:OnEnterPressed"]:1>
1x BiSTracker\core\ChatCommands.lua:34: attempt to index upvalue 'L' (a nil value)
[string "@BiSTracker\core\ChatCommands.lua"]:34: in function 'Help'
[string "@BiSTracker\core\ChatCommands.lua"]:60: in function '?'
[string "@Ace3\AceConsole-3.0\AceConsole-3.0-7.lua"]:94: in function '?'
[string "@FrameXML\ChatFrame.lua"]:4825: in function <FrameXML\ChatFrame.lua:4771>
[string "=[C]:"]: in function 'ChatEdit_ParseText'
[string "@FrameXML\ChatFrame.lua"]:4488: in function <FrameXML\ChatFrame.lua:4487>
[string "=[C]:"]: in function 'ChatEdit_SendText'
[string "@FrameXML\ChatFrame.lua"]:4524: in function 'ChatEdit_OnEnterPressed'
[string "*:OnEnterPressed"]:1: in function <[string "*:OnEnterPressed"]:1>
1x BiSTracker\core\Init.lua:276: attempt to call method 'IsVisible' (a nil value)
[string "@BiSTracker\core\Init.lua"]:276: in function 'ToggleOptions'
[string "@BiSTracker\core\ChatCommands.lua"]:47: in function 'ToggleOptions'
[string "@BiSTracker\core\ChatCommands.lua"]:68: in function '?'
[string "@Ace3\AceConsole-3.0\AceConsole-3.0-7.lua"]:94: in function '?'
[string "@FrameXML\ChatFrame.lua"]:4825: in function <FrameXML\ChatFrame.lua:4771>
[string "=[C]:"]: in function 'ChatEdit_ParseText'
[string "@FrameXML\ChatFrame.lua"]:4488: in function <FrameXML\ChatFrame.lua:4487>
[string "=[C]:"]: in function 'ChatEdit_SendText'
[string "@FrameXML\ChatFrame.lua"]:4524: in function 'ChatEdit_OnEnterPressed'
[string "*:OnEnterPressed"]:1: in function <[string "*:OnEnterPressed"]:1>
Nuking saved variables seems to have gotten rid of the load errors.
To the tune of
/run BiS_Settings=nil;BiSTrackerDB=nil;ReloadUI()
Attempting to drag the bistracker frame from the titlebar area seems to render it unclickable (both the main frame and all children, dropdowns etc)
At a quick look a whole bunch of frames that would be expected to be parented to the main frame are not added to a container as children so just clicking the title of the main window seems to mess up a bunch of other frames.
I'm gonna take a look at the parenting/children issue tomorrow. If this is really the reasoning behind the bug that renders the add-on completely useless, then I would never have realized it. Thank you :) I will also take a look at the other issues.
The documentation is lacking for Window
type but Frame
should be close (and all container types share basic container API)
If it helps any.
Do you have any idea which frames aren't parented? I'm looking through but having trouble finding them.
I found two, being the custom set delete confirmation, as well as the edit slot window.
They for some reason simply don't want to parent to the main frame, regardless of me using :AddChild on the mainframe, or the SetParent on the child frame. They still don't parent.
Not really a fix but a workaround to prevent the standalone frame from breaking is to nix the mousehandlers on the title.
BiSTracker.MainFrame.title:SetScript("OnMouseDown", nil)
BiSTracker.MainFrame.title:SetScript("OnMouseUp", nil)
After MainFrame is created.
This doesn't make the frame draggable but it wasn't dragging before and at least it won't break on clicking title.
When it's attached to CharacterFrame there is still an issue but I didn't have time to look for a workaround there.
Okay I managed to get the unparented frames parented to the mainframe, however it still does not fix the issue with moving the window. This might just come down to rewriting it without using AceGUI.
The issue seems to be with the OnMouseUp handler then either ClearFocus or StartMoving breaking MouseEnabled and / or anchoring for all anchor chains.
If the frame is anchored to the CharacterFrame then it breaks that, even if you break the parent child relationship (no :SetParent).
Something really strange is happening that I haven't been able to figure out. AceGUI is used extensively in the addon space though, it's surprising that it would break in such a way.
The workaround I posted is not fixing anything obviously, it just prevents the user from taking the action that breaks it, hiding the problem.
This wasn't an issue till one of the latest client updates. I can't say exactly which one as I have no idea, however nothing changed in my code in between it working and it breaking. Hence why I'm close to just giving up on it.
Right, with that hint I'm 99.9% certain the issue is this Stanzilla/WoWUIBugs#136
Reference of it bugging a default frame Stanzilla/WoWUIBugs#135
That's exactly the behavior of BiSTracker.
Edit: That also means that you would have to painstakingly review your anchors until you find what is misbehaving with no assistance from the client in the form of errors (which is what that bug filing is essentially about)
That's interesting, as the main frame has two anchors, one being center of UIParent, and one being the characterframe. The mainframe isn't the only one having the same anchor points tho, as all the other (3) windows are anchored to the mainframe, as well as center in UIParent, however they function as you would expect.
Could the issue of the mainframe occur due to a child having bad anchors?
Rip. That's gonna be incredibly tedious.
Admittedly, the codebase isn't really at a point where maintenance is easy. Semi-spaghetti. Definitely better than v1, but still not up to what I would consider my standards by now.
I am unsure however, if a rewrite would benefit the people who use it or if it would be more or less a waste of time.
What happens if you just fix the MainFrame anchoring? Is it still broken?
I mean if you start from there instead of diving into children straight away.
The culprits do indeed seem to be the three floating boxes, being "BiSTracker.MainFrame.ConfirmDelete", "BiSTracker.MainFrame.EditSlot", and "BiSTracker.Serializer.GUI" (The import/export frame).
This makes me feel real stupid, not gonna lie.
I attempted to clear all points on the culprit frames before I anchor it to the mainframe, and low and behold, it worked.
I didn't realize it before even when it was right in my face, as I thought nothing of it, however AceGUI frames anchor to the center of UIParent by default, and that seemed to feed right into the issue you linked me.
Even though the frames are not actually children of the mainframe it still seemed to brick it, which doesn't really make sense with the issue you sent me.
Either way, clearing the anchors on the popup frames fixed the issue.
Interestingly enough, without having fiddled with it even in the slightest, the chat commands work now aswell. Odd how a bug in the UI can introduce a bug in the chat when they have no correlation whatsoever.
Lastly I'm gonna attempt to upgrade from an old version of the addon. Do you have any idea what version you had installed that introduced the issues? I suspect it might be a problem with migrating custom data, however over the course of the addon I have had 3 different data templates.
Considering this is something that might get ameliorated in a client patch I'd hold off on major rewrites.
You could try to have everything that should be a child of mainframe anchored relative only to it and mainframe itself avoiding cross-family anchors.
That obviously doesn't apply to the options frame or the popup frames (they might "conceptually" be spawned from mainframe actions but they don't need to be its children), although if they support dragging they would also have to be properly anchored themselves.