Addon system bug reports

[ZorbaTHut]

*.Event:LeftDown() seems to now trigger for each frame no matter which one was clicked. Double checked with your buff bars example, and it does indeed now cancel all buffs when clicking just one.

*.Event:LeftUp() has now stop reporting entirely.

We're in the middle of redesigning the mouse event backend and the implementation may be flaky for a little bit. We'll keep you posted.

[fatalus]

No rendering with the return value ".level of "Inspect.Unit.Detail(..)" with :SetText of "UI.CreateFrame("Text", ..."

My Workaround is ":SetText(level.." ");"

[ZorbaTHut]

No rendering with the return value ".level of "Inspect.Unit.Detail(..)" with :SetText of "UI.CreateFrame("Text", ..."

My Workaround is ":SetText(level.." ");"

You can also do tostring(level). It's a number, not a string, so I'm not sure we should be trying to display it. I'll think about this one, though.

[hp94]

We're in the middle of redesigning the mouse event backend and the implementation may be flaky for a little bit. We'll keep you posted.

Ya, a lot of my OnClick type events are acting differently than I expected. Should I just wait until we get the go-ahead before trying to program around it?

[ZorbaTHut]

Ya, a lot of my OnClick type events are acting differently than I expected. Should I just wait until we get the go-ahead before trying to program around it?

Probably, yeah. Work on other parts of your addon

[Kreiri]

sometimes Event.Ability.Cooldown.* gives spell IDs, for which Inspect.Ability.Detail returns nil.
Example:
a0000000030042499 - Flicker

[Padawan]

This could be me not understanding the function usage

context = UI.CreateContext("test");
frame = UI.CreateFrame("Frame", "Test", context);
frame:SetSecureMode("restricted");

[Test] stack traceback:
[Test] 	[string "Rift core"]:231: in function <[string "Rift core"]:230>
[Test] 	[C]: in function 'SetSecureMode'
[Test] 	Test/core.lua:3: in function 'func'
[Test] 	[string "Rift core"]:229: in function <[string "Rift core"]:228>
[Test] 	[C]: in function 'xpcall'
[Test] 	[string "Rift core"]:228: in function <[string "Rift core"]:227>

Is apparently incorrect but

frame:SetSecureMode("normal");

works fine. In both cases calling the function while not in secure mode, I'll admit I could be missing something obvious.

[Semele]

This could be me not understanding the function usage

context = UI.CreateContext("test");
frame = UI.CreateFrame("Frame", "Test", context);
frame:SetSecureMode("restricted");

[Test] stack traceback:
[Test] 	[string "Rift core"]:231: in function <[string "Rift core"]:230>
[Test] 	[C]: in function 'SetSecureMode'
[Test] 	Test/core.lua:3: in function 'func'
[Test] 	[string "Rift core"]:229: in function <[string "Rift core"]:228>
[Test] 	[C]: in function 'xpcall'
[Test] 	[string "Rift core"]:228: in function <[string "Rift core"]:227>

Is apparently incorrect but

frame:SetSecureMode("normal");

works fine. In both cases calling the function while not in secure mode, I'll admit I could be missing something obvious.

Although the Error received is ambiguous, I figured it was something to do with the parent chain also not having the "restricted" flag set.

If you change your example to below, it'll work. So make sure every parent is in restrictive mode also.

context = UI.CreateContext("test");
context:SetSecureMode("restricted");
frame = UI.CreateFrame("Frame", "Test", context);
frame:SetSecureMode("restricted");

The above should work. Took some head-scratching, but the usual epiphany while drifting off to sleep had me test this today.

[Padawan]

Ah thanks.

[BRG]

The .duration fields of a buff's details (fetched via Inspect.Buff.Details) is inconsistent for buffs with no duration (those that last forever). I've tested a few buffs and I know that a shaman's passive buffs (Heart and Courage spells) will have .duration = nil. On the other hand, the Rested buff and a justicar's Mien spells have a buff duration of 0.

Although trivial to work around, I imagine that these no duration buffs should all have the same .duration field.

[Levva]

	local unitdetail = Inspect.Unit.Detail("group02")

This seems to return nil if the player identified by "group02" is offline, yet the default UI knows that the player exists. Is there something odd when using a unitSpecifier in Inspect.Unit.Detail vs a unitID?

It kind of makes the .offline value of Inspect.Unit.Detail redundant if you can't get to the parent object when the player is offline.

[ZorbaTHut]

	local unitdetail = Inspect.Unit.Detail("group02")

This seems to return nil if the player identified by "group02" is offline, yet the default UI knows that the player exists. Is there something odd when using a unitSpecifier in Inspect.Unit.Detail vs a unitID?

It kind of makes the .offline value of Inspect.Unit.Detail redundant if you can't get to the parent object when the player is offline.

I can't reproduce this - it was true at one point, but it was fixed about a month ago. Can you doublecheck?

I'm logging in two characters, joining a group, having the non-leader log off, and doing "/script dump(Inspect.Unit.Detail("group02"))" on the remaining character. I get {name = "CharacterName", offline = true}.

Note that the group IDs can have unexpected ordering - make sure the dump() works properly when they're logged on, I *think* it preserves the group ordering when someone logs off. Worst-case, try everything from group01 through group05, or hook Event.Unit.Detail.Offline.

[Levva]

I'll investigate further this evening (10:05am UK time here). My current code is doing a loop from group01-group20 to check all possible raid members and skipping if nil returned. I was in a test party checking syntax of new role feature, having got the role stuff working I thanked the guy helping me and he disconnected rather than logging off thus leaving him in the party and the UI showing him as offline. However my code was no longer detecting him.

Tonight I'll pop round to mates and bug him to login/out several times so I can test things and see if I can come up with sample code illustrating the issue. (Assuming of course there is an issue and the bug isn't in my code).

[ZorbaTHut]

Tonight I'll pop round to mates and bug him to login/out several times so I can test things and see if I can come up with sample code illustrating the issue. (Assuming of course there is an issue and the bug isn't in my code).

Let me know what you figure out If it helps, here's the one-line test script I just used to try out raids:

/script print("---") for i = 1, 20 do local dat = Inspect.Unit.Detail(string.format("group%02d", i)) if dat then dump(i, dat) end end

[Levva]

Let me know what you figure out If it helps, here's the one-line test script I just used to try out raids:

/script print("---") for i = 1, 20 do local dat = Inspect.Unit.Detail(string.format("group%02d", i)) if dat then dump(i, dat) end end

Thanks for script. Tested and it is working I had a test in to see if unit was a player to filter out pet objects and targets etc which was required when I used Inspect.Unit.List but now I use "groupxx" it is overkill to test if unit.player is true.

My code was failing because I'd not noticed that an offline player has no return value for the .player attribute. When I reported the bug I hadn't checked where the nil was I just noted it wasn't getting to the debug line I had after the test to see if Inspect.Unit.Detail returned an object. Unfortunately that test tested both that the object existed and the .player attribute was true. Hence the failure which I attributed to a nil value from Inspect.Unit.Detail. Sorry about that.