Addon system bug reports

[Snowreap]

that works if your settings table is shallow (i.e. it contains no subtables). but if your settings table has subtables, those subtables get copied in their entirety, so you lose new defaults that are buried farther down.

-ken

[dOxxx]

This does not behave the way I would expect it to:

local context = UI.CreateContext("blah")
local frame = UI.CreateFrame("Frame", "blah2", context)
frame:SetBackgroundColor(1, 1, 1, 1)
frame:SetPoint("TOPLEFT", UIParent, "TOPLEFT", 100, 100)
frame:SetWidth(500)
frame:SetHeight(500)
frame:SetPoint("BOTTOMRIGHT", UIParent, "TOPLEFT", 200, 200)

This is a contrived example, but the point is that if width and height are set on a frame, then if at some later point BOTTOMRIGHT is set, it has no effect. This is counter-intuitive, since setting BOTTOMRIGHT is implicitly affecting the width and height and should replace the original settings.

I know I can use ClearAll in before setting the BOTTOMRIGHT but then I have to set up the frame's anchoring from scratch.

I'm wondering how I can accomplish something like RiftTextfield's default sizing on my own Frame without using SetWidth or SetHeight.

Edit: A better workaround is to use ClearWidth and ClearHeight.

[ZorbaTHut]

This is a contrived example, but the point is that if width and height are set on a frame, then if at some later point BOTTOMRIGHT is set, it has no effect. This is counter-intuitive, since setting BOTTOMRIGHT is implicitly affecting the width and height and should replace the original settings.

On the PTS, doing this will generate an error message. It's possible this should be a warning - we'll be evaluating the actual impact of turning this into an error - but in any case, it's now a loud complaint from the addon system.

Note that it's not a problem with BOTTOMLEFT specifically, it's an issue with overspecifying frames. You can't set two points *and* a size on an axis because those three values may conflict. Same issue with three points - what happens if we set TOPLEFT=100,100, CENTER=200,200, BOTTOMRIGHT=400,400? There's simply no way to resolve those constraints.

The reason we can't just replace the original settings is that it's unclear which part of the settings should be replaced. Should it replace width/height or TOPLEFT? Either option would result in a consistent result, but they obviously mean very different things.

That said, you could change the SetWidth/SetHeight lines to frame:SetPoint("BOTTOMRIGHT", frame, "TOPLEFT", 500, 500) and it would just sort of work.

[ZorbaTHut]

I realize people probably haven't thrown many large tables at the addon system yet, I'd just like to know if this is a fixable limitation or are we stuck at 65K variables? Imagine writing an auctioneer addon with a limit of 65K table entries

The restriction isn't with the size of a Lua table, it's with the impact on the parser to load a monolithic block of data. Assuming I'm reading this correctly, you're limited to 65536 constants, either in a single file or in a single line of code. I suspect the latter.

Right now, you have:

RiftItems = {
  ["BigKeyHere"] = {["Parameter"] = "Data"},
  ["BiggerKeyHere"] = {["Parameter"] = "Data"},
}

Try transforming things to look more like:

RiftItems = {}

RiftItems["BigKeyHere"] = {Parameter = "Data"}
RiftItems["BiggerKeyHere"] = {Parameter = "Data"}

No guarantees, but I suspect that will improve matters.

[dOxxx]

On the PTS, doing this will generate an error message. It's possible this should be a warning - we'll be evaluating the actual impact of turning this into an error - but in any case, it's now a loud complaint from the addon system.

Note that it's not a problem with BOTTOMLEFT specifically, it's an issue with overspecifying frames. You can't set two points *and* a size on an axis because those three values may conflict. Same issue with three points - what happens if we set TOPLEFT=100,100, CENTER=200,200, BOTTOMRIGHT=400,400? There's simply no way to resolve those constraints.

The reason we can't just replace the original settings is that it's unclear which part of the settings should be replaced. Should it replace width/height or TOPLEFT? Either option would result in a consistent result, but they obviously mean very different things.

That said, you could change the SetWidth/SetHeight lines to frame:SetPoint("BOTTOMRIGHT", frame, "TOPLEFT", 500, 500) and it would just sort of work.

Thanks for the explanation. I was wondering then how does the RiftTextfield, etc. set their default sizes without us encountering this problem when we then subsequently try to anchor them?

[ZorbaTHut]

Thanks for the explanation. I was wondering then how does the RiftTextfield, etc. set their default sizes without us encountering this problem when we then subsequently try to anchor them?

They use a different and easily-overridable method of setting size that isn't available for the outside world to use. Essentially they just change their defaults.

[TinnerKB]

When logging in from character screen, UIParent:GetWidth() and UIParent:GetRight() take their values from the base graphics settings. ie. 1280x960 and such. It doesnt see the values set in the Global UI scale in the interface display settings until you do a /reloadui. Example of this is the addon FooBar. I have the global ui scale set at 75, places my screen about 1700 instead of 1280. When logging in, the addon bar is about 2/3 of the way across my screen. Once I do a /reloadui it will then expand the total screen width.
If I logout and login on another alt it happens again.

[the_real_seebs]

slider:SetPosition appears not to like non-integer arguments.

This isn't EXACTLY a bug. But what will happen if no two people working around it pick the same solution will be. Please make SetPosition do something consistent and documented with non-integer arguments, probably just math.floor(x + 0.5) or something cheezy like that.

[dOxxx]

RiftTextfield should automatically lose key focus when it is no longer visible, due to SetVisible(false) being called on either itself or one of its ancestors.

It is very difficult to workaround this since there is no easy way to determine when a frame is no longer visible, without hooking SetVisible in the frame and all its ancestors, which would be tedious to say the least.

[Aieny]

print (Utility.Item.Slot.Bank("main",1))
print (Utility.Item.Slot.Bank("bag",1))

These generate incorrect function usage errors.

[ZorbaTHut]

print (Utility.Item.Slot.Bank("main",1))
print (Utility.Item.Slot.Bank("bag",1))

These generate incorrect function usage errors.

We'll fix those. Thanks for testing the new API

[Xenyr]

local txtFrame = UI.CreateFrame("RiftTextfield", "Texty", parentFrame)
txtFrame:SetText("{A}")
print(txtFrame:GetText())

The above code snippet will print out "A}" rather than "{A}" as it should. Looks like the textfield is stripping the opening brace character.

[Aieny]

Event.Achievement.Update is being called during startup, which may or may not be a bug, but there is a crash bug that happens if you call Inspect.Achievement.Detail too soon.

At the end of my core.lua file, I have

table.insert (Event.Achievement.Complete, {altAchievementComplete, "Altometer", "AchievementComplete"})
table.insert (Event.Achievement.Update, {altAchievementUpdate, "Altometer", "AchievementUpdate"})

, so the function is being inserted into the event table during the Addon startup.

The function is

function altAchievementUpdate(params)
	print ("Achievment Updated!")
	for key,value in pairs(params) do
		achDetail = Inspect.Achievement.Detail(key)
		print ("------------------------------")
		dump_table(achDetail)
	end
end

After doing some serious work, I isolated the bug to the achDetail = Inspect.Achievement.Detail(key) line, which, when commented out, does not cause a crash. I printed out just the keys in the loop, and they all appear just fine, so there is something going on in the actual inspector that is causing the crash if it is called too early.

An additional note, this only started happening after the most recent update to the PTS. Before that, it worked just fine. I also haven't had a chance to test if it is an error that happens all the time, but it definitely occurs during startup.

[ZorbaTHut]

Event.Achievement.Update is being called during startup

This isn't a bug - at the very beginning of startup, the client isn't aware of the player's achievement status. .Update will be called once the real data is downloaded and signals that, yeah, you should probably update.

but there is a crash bug that happens if you call Inspect.Achievement.Detail too soon.

This is, though Thanks for the report!

[dOxxx]

If you have two frames attached to each with no space between them (i.e. frame A's right side is attached to frame B's left side), when you mouseover from one from to the other and back, sometimes you will get the MouseIn/MouseOut events out of order. i.e. You will get the MouseIn event of the frame you moving into before you get the MouseOut event from the frame you are exiting. Only seems to happen when moving from one specific frame to the other and not in the reverse order, so it may have something to do with the order in which the frames were created.