Error With my UI/Addons

[emiaee]

Hello,

Recently I've put together a nice compilation for myself and tried to write an addon for myself and also used some scripts I've found on the internet as well. Everything seems to work fine however sometimes I get this random amount of (varying from 36 to 82 - mostly as I could observe xloot, whoaUnitframes and tidyplates) errors on my BugSack/BugGrabber and WoW Chat Log informs me about lots of interface errors may cause something bad.

I've attached my addons in the link from my google drive below with my WTF folder/saved variables however folders are renamed. Also I have shared the notepad of errors I get.

If anyone could help me out I would be more than grateful and happy! Thank you for taking your time even reading my thread!

Addon Compilation / UI:
https://drive.google.com/file/d/0B1M...it?usp=sharing

Errors that I copy pasted from bugsack/buggrabber:
https://drive.google.com/file/d/0B1M...it?usp=sharing

For anything:
email address removed, PM if you want to contact emiaee privately ~ Cairenn


Thank you very much! (I'm pretty new here so I hope this is the correct topic to post this under)

[Phanx]

1) Posting your email address in plaintext on a public forum is basically sending out a party invitation to all the spammers of the world. I'd recommend removing it; people who really want to contact you privately can send you a PM on the forums, or (if you've enabled it) send you email through the forum's contact form, which doesn't reveal your email address, but most likely people will prefer just to reply here in the thread.

2) Before doing anything else, make sure you have the latest release versions of all of your addons. If you're using alpha or beta versions, try rolling back to the last release version. Then, for the addons that are still raising errors, go through some basic troubleshooting steps to try to resolve the problem.

3) After looking at the code for Broker Everything I have a strong desire to gouge my eyes out with a blunt object and pour Tabasco sauce in afterwards, but it looks like the problem is related to mousing over an equipment slot that the addon doesn't recognize. Figure out which slot is causing the error, and then report the problem to the addon's author so they can fix it (and ideally rewrite the horrifying entirety of their code).

4) The errors from XLoot and whoaUnitFrames are standard taint errors. The Blizzard taint reporting system is notoriously unreliable, so it's possible these addons aren't even causing the problem, but following the steps in the troubleshooting guide linked above (specifically, the part where you disable all other addons) will tell you for sure. If it turns out these addons are responsible for the errors, report them to the addons' authors so they can be fixed.

[emiaee]

Originally Posted by Phanx 1) Posting your email address in plaintext on a public forum is basically sending out a party invitation to all the spammers of the world. I'd recommend removing it; people who really want to ...

Thank you for your response and advice regarding email, although I believe the forum admin beat me to it and removed it before I could so I thank him as well.

Regarding Broker_everything causing the error what should I exactly look for in their code or in the game? I may have a possible reason why the errors pop, which I can relate to as in such: I know that hovering over which certain objects in my broker bar (bazooka used) may be popping the errors after UI reload.

Also with the MheerUI.lua I have hidden some objects with the most straightforward and simplistic commands I could. Since I'm not familiar with Lua can it be causing any errors? For example hiding the compact raid frame or scaling unit frames etc.?

[Phanx]

Originally Posted by emiaee Regarding Broker_everything causing the error what should I exactly look for in their code or in the game? I may have a possible reason why the errors pop, which I can relate to as in such: I know that hovering over which certain objects in my broker bar (bazooka used) may be popping the errors after UI reload.

If you know the specific actions that cause the error, post a bug report on the addon's download page. Include the error message and the steps the author should follow to reproduce the bug.

Originally Posted by emiaee Also with the MheerUI.lua I have hidden some objects with the most straightforward and simplistic commands I could. Since I'm not familiar with Lua can it be causing any errors? For example hiding the compact raid frame or scaling unit frames etc.?

Yes, this can absolutely cause errors. You can't overwrite methods on secure frames at all, and you can't hide, show, move, scale, or do many other things with secure frames while in combat.

[emiaee]

Originally Posted by Phanx Yes, this can absolutely cause errors. You can't overwrite methods on secure frames at all, and you can't hide, show, move, scale, or do many other things with secure frames while in combat.

The MheerUI does not display error on my bugsack I asked this because of errors with Compact Raid Frames etc. Would the errors be under MheerUI or since it hides the Compact Raid Manager does all compact raid items are related to MheerUI?

Is there any other way to hide these "secure frames" like a texture pack etc? Several suites hide them successfully

If you do not wish to download the addon package I can copy paste the Lua in MheerUI here as well.

[Phanx]

Like I said, Blizzard's taint reporting system is essentially worthless for anything beyond telling you "something has been tainted". Taint isn't like a syntax error -- taint just means that something in addon code touched something in Blizzard code that isn't allowed to be touched. You don't generally get an error right away when you taint something. The error only occurs later, when the secure code is trying to run, and finds that part of itself was touched by an addon. At that point an error will occur, but it almost never correctly identifies the addon that actually caused the problem.

Looking through your code, you're basically tainting everything you touch:

BuffFrame.SetPoint = function() end

The buff frame is now tainted. Since the buff frame itself isn't a secure frame, you won't get an error directly, but if it were secure, then you would get an error the next time Blizzard code tried to move it while in combat. And even though it's not secure, it's still "protected" and you will probably get an error if you try to right-click off buffs while in combat.

Most of the other frames you're tainting (by overriding their methods) are neither secure nor protected, so this technique is fine, but this will absolutely cause problems:

CompactRaidFrameManager.Show = function() end

This is probably why you're getting all of those taint errors about compact raid frames.

If you don't use the default raid frames, you can remove both the default raid frames and the raid frame manager by disabling the Blizzard addons that provide them:

/run DisableAddOn("Blizzard_CUFProfiles") DisableAddOn("Blizzard_CompactRaidFrames") ReloadUI()

To re-enable them later, replace DisableAddOn with EnableAddOn.

If you do use the default raid frames, and just want to hide the raid frame manager, you'll have to use non-tainting methods of hiding it, eg.

CompactRaidFrameManager:UnregisterAllEvents()
CompactRaidFrameManager:Hide()

If it continues appearing, you'll have to look through the default UI code to figure out what's causing it to be shown, and find a way to work around it.

[emiaee]

Originally Posted by Phanx Like I said...

First of all thank you for taking your time helping me out with this and keeping up with someone who, as you see, has literally trying to make up things by himself without former knowledge.

What I understood if that running "/run DisableAddOn("Blizzard_CUFProfiles") DisableAddOn("Blizzard_CompactRaidFrames") ReloadUI()" once would solve my problems with hiding the raid manager and raid frames (default ones.)

Also does only these "BuffFrame.SetPoint = function() end" lines cause the problem or the moment I touch the location, size or anything regarding protected frames (Buff frames in this case) cause the taint itself? If so how can I move anything without tainting it if it is possible?

What I ask is if I remove these lines:
FRAME_NAME.Show = function() end
FRAME_NAME.SetPoint = function() end
will the tainting stop? :P

Thank you for your time again!

[Phanx]

Originally Posted by emiaee Also does only these "BuffFrame.SetPoint = function() end" lines cause the problem or the moment I touch the location, size or anything regarding protected frames (Buff frames in this case) cause the taint itself?

That line causes the taint, but the taint does not be come a problem until it gets in the way of an action like moving a secure frame in combat or calling a protected function that cannot be done from tainted code. In the case of the buff frames, the taint won't be a problem until you try to click off a buff while in combat.

Technically, all addon code is tainted, and any Blizzard code you touch from an addon also becomes tainted. Taint by itself is not a problem. You just have to be careful about what you taint, and avoid tainting secure frames or code paths that lead to calling protected functions.

Originally Posted by emiaee If so how can I move anything without tainting it if it is possible?

It depends on what you're trying to move/hide. If it's a Blizzard frame, then this will often work to hide it:

frame:UnregisterAllEvents()
frame:Hide()

For unit frames, you also need to do "UnregisterUnitWatch(frame)" before the above.

This will also work without causing taint:

frame:HookScript("OnShow", frame.Hide)
frame:Hide()

... but it won't work for secure frames that are shown in combat, because addon code isn't allowed to :Hide() secure frames in combat.

For moving things, it's just not possible for secure frames if Blizzard code moves them in combat (you have to wait until combat ends) but for other things you can hook their SetPoint method to detect when Blizzard code moves them, and move them back to where you want:

local moving
hooksecurefunc(frame, "SetPoint", function(self, ...)
     if moving then return end -- avoid infinite loops
     moving = true
     frame:SetPoint("TOPLEFT", UIParent, 100, -100)
     moving = nil
end)

If the frame is secure, then you need to check "if moving or InCombatLockdown()" instead of only "if moving", since addons are not allowed to move secure frames in combat.

For insecure frames that don't call any protected functions, you can just override the ClearAllPoints and SetPoint methods with an empty function like you're currently doing with Show.

[emiaee]

Originally Posted by Phanx That line causes the taint...

Thank you for your explanation and helps, by this you actually fixed all of my bug messages. However I have problem with executing:

local moving
hooksecurefunc(frame, "SetPoint", function(self, ...)
     if moving then return end -- avoid infinite loops
     moving = true
     frame:SetPoint("TOPLEFT", UIParent, 100, -100)
     moving = nil
end)

Does this function let the frames go to their original spot in the combat and when the combat ends go back to the location I hook them to? I tried this with the buffs but could not tell the difference and they did not move to where I wanted to put them, that is top right of the screen and mini map border top left 36, -26. They remain the same place (default place) always.

Apart from that I should retain from using

Frame.SetPoint = function() end

for moving and/or scaling any frame to retain from a taint if I understand correctly since it overrides all actions for that frame and when Blizz's code calls for such frame the code that overrides it "taints" the object? I hope I got it right.

Also some frames (ex: BuffFrames) move without using BuffFrame.SetPoint = function() end code whereas the castbar does not move without CastingBarFrame.SetPoint = function() end, full code for them are listed below in MheerUI;

BuffFrame:ClearAllPoints();
BuffFrame:SetPoint("TOPRIGHT", "MinimapBorderTop","TOPLEFT", 36, -26);
 
(I have deleted the line BuffFrame.SetPoint = function() end in my revised version)

and

CastingBarFrame:ClearAllPoints();
CastingBarFrame:SetPoint("BOTTOM", 0, 115);
CastingBarFrame.SetPoint = function() end

If I remove the last line for casting bar, it moves to the default spot whereas the buff frames do not require that line. Is it due to the extra location that is defined for the Buff Frames anchoring them to the top left of the Mini map border?

[Phanx]

Originally Posted by emiaee Does this function let the frames go to their original spot in the combat and when the combat ends go back to the location I hook them to?

No, it will only work out of combat, since it's not possible for an addon to move a secure frame while in combat. If you're working with a frame that Blizzard code moves while in combat, then you'll need to listen for the PLAYER_REGEN_ENABLED event (which tells you when combat ends) and manually move the frame back to the desired location afterward.

Originally Posted by emiaee I tried this with the buffs but could not tell the difference and they did not move to where I wanted to put them, that is top right of the screen and mini map border top left 36, -26. They remain the same place (default place) always.

You still need to move them once manually; the hook I posted will only move a frame back to your desired location when Blizzard code moves it somewhere else.

frame:ClearAllPoints()
frame:SetPoint(--[[ your points here ]])
-- hook code from my previous post here

Also, if the point you're setting is different than the point set by Blizzard code (eg. you're anchoring the frame by its TOPRIGHT point, but Blizzard code anchors it by its BOTTOMLEFT point) then you need to add a ClearAllPoints line inside the hook.

Originally Posted by emiaee Apart from that I should retain from using <snip> for moving and/or scaling any frame to retain from a taint if I understand correctly since it overrides all actions for that frame and when Blizz's code calls for such frame the code that overrides it "taints" the object? I hope I got it right.

For frames that are not secure and don't call any protected functions, you can continue overriding the SetPoint method, as this is more efficient than using a hook. However, for frames that are secure (like action buttons or unit frames), or frames that call protected functions (like buff icons call a protected function when you right-click them), yes, you should not use that method.

Originally Posted by emiaee Also some frames (ex: BuffFrames) move without using BuffFrame.SetPoint = function() end code whereas the castbar does not move without CastingBarFrame.SetPoint = function() end

If Blizzard code never moves a frame after creating it, then you don't need to hook or overwrite SetPoint after moving it to your desired location. This is probably the case for the buff frames, and if so, you don't need to use the SetPoint hook on the buff frames either.

However, Blizzard code does move the castbar after creating it, which is why you have to hook or overwrite its SetPoint method.