WoWInterface (
-   General Authoring Discussion (
-   -   FrameLocks.lua and target taint (

Grimsin 09-27-12 12:06 PM

FrameLocks.lua and target taint
So i have a taint issue. After going into a pet battle my target frame becomes tainted and any time i change targets in combat after a petbattle it fires taint errors. The problem is with the new FrameLocks.lua

my code hides and locks out the original bliz targetframe. This new framelocks.lua does this...
Lua Code:
  1. ----------Local helper functions---------------
  2. local function initiateFrame(frame)
  3.     local frameName = frame:GetName();
  4.     if ( not frameName or frameName == "" ) then
  5.         GMError("Frames controlled by FrameLocks must have names.");
  6.     end
  8.     if ( BASE_STATES[frameName] ) then
  9.         return;
  10.     end
  12.     BASE_STATES[frameName] = frame:IsShown() and "shown" or "hidden";
  13.     assert(frame.originalShow ~= frame.Show); --Make sure we didn't already set up this frame.
  14.     frame.originalShow = frame.Show;
  15.     frame.originalHide = frame.Hide;
  16.     frame.Show = SmartShow;
  17.     frame.Hide = SmartHide;
  18. end
  20. local function updateFrameByState(frame)
  21.     initiateFrame(frame);
  22.     local frameName = frame:GetName();
  23.     if ( not frameName or frameName == "" ) then
  24.         GMError("Frames controlled by FrameLocks must have names.");
  25.     end
  26.     for i=1, #FRAMELOCK_STATE_PRIORITIES do
  27.         local lock = FRAMELOCK_STATE_PRIORITIES[i];
  28.         if ( ACTIVE_FRAMELOCKS[lock] ) then
  29.             local desiredState = FRAMELOCK_STATES[lock][frameName];
  30.             if ( desiredState == "hidden" ) then
  31.                 frame:originalHide();
  32.                 return;
  33.             elseif ( desiredState == "shown" ) then
  34.                 frame:originalShow();
  35.                 return;
  36.             end
  37.         end
  38.     end
  40.     --If we got to here, no lock is in place, so use the base state.
  41.     if ( BASE_STATES[frameName] == "shown" ) then
  42.         frame:originalShow();
  43.     else
  44.         frame:originalHide();
  45.     end
  46. end

I think the taint is created because my addon cancels the orignal hide and show functions via
Lua Code:
  1. function addon:HideFrame(reference)
  2.     local frame = type(reference) == 'string' and _G[reference] or reference
  3.     if type(frame) ~= 'table' then return end
  4.     frame.Show = DoNothing
  5.     frame:Hide()
  6. end

and this is the actual hiding of it...
Lua Code:
  1. --[[-----------------------------------------------------------------------------
  2. Configure Bliz Target Frame
  3. -------------------------------------------------------------------------------]]
  4. function addon:ConfigureBlizTargetFrame()
  5.     if addon.settings.hideBlizTargetFrame then
  6.         addon:HideFrame('TargetFrame')  -- come back to this and put in unregisters but watch out for buffs :)
  7.     else
  8.         TargetFrame.Show = TargetFrame:Show()
  9.         TargetFrame:RegisterEvent("PLAYER_TARGET_CHANGED")
  10.         TargetFrame:RegisterEvent("UNIT_HEALTH")
  11.         TargetFrame:RegisterEvent("UNIT_LEVEL")
  12.         TargetFrame:RegisterEvent("UNIT_FACTION")
  13.         TargetFrame:RegisterEvent("UNIT_CLASSIFICATION_CHANGED")
  14.         TargetFrame:RegisterEvent("UNIT_AURA")
  15.         TargetFrame:RegisterEvent("PLAYER_FLAGS_CHANGED")
  16.         TargetFrame:RegisterEvent("PLAYER_FOCUS_CHANGED")
  17.         if UnitExists("target") then TargetFrame:Show() end
  18.     end
  19. end
  21. addon.RegisterEvent("TargetFrame-Prime", 'PLAYER_LOGIN', function(self, event)
  22.     addon.UnregisterEvent(self, event)
  23.     addon:ConfigureBlizTargetFrame()
  24. end)

Any ideas for turning the framelock.lua off?

Grimsin 09-27-12 05:09 PM

heres what the taint log produces... Chat frame 11? ummm my chat setup only goes to 8?

9/27 16:05:26.989  Execution tainted by GrimUI while reading ChatFrame11 - Interface\FrameXML\FloatingChatFrame.lua:1105 FCF_OnUpdate()
9/27 16:05:26.989      UIParent:OnUpdate()
9/27 16:05:26.989  An action was blocked in combat because of taint from GrimUI - TargetFrame:originalHide()
9/27 16:05:26.989      Interface\FrameXML\FrameLocks.lua:90 updateFrameByState()
9/27 16:05:26.989      Interface\FrameXML\FrameLocks.lua:101 setBaseState()
9/27 16:05:26.989      Interface\FrameXML\FrameLocks.lua:116 TargetFrame:Hide()
9/27 16:05:26.989      Interface\FrameXML\TargetFrame.lua:99 TargetFrame_Update()
9/27 16:05:26.989      Interface\FrameXML\TargetFrame.lua:150 OnEvent()
9/27 16:05:26.989      Interface\FrameXML\UnitFrame.lua:489

Grimsin 09-27-12 05:42 PM

Can someone point me to where the pet battle chatframe gets created? is that in chatframes? floatingchatframes? the petbattle ui?

Phanx 09-27-12 09:34 PM

The problem in your original post is that you are replacing the Show and Hide methods on the frame; this taints the secure frame. If you want to hide the target frame without tainting it, you need to do it without overwriting anything on it. Try this instead:




Note that these must be run out of combat.

If you want to "hide" the frame based on certain conditions, you can either use a secure state driver that shows or hides the frame based on macro conditionals, or you can change the opacity of the frame to 0% to visually hide it if you want to "hide" it based on conditions that aren't allowed in macros like health.

Without seeing the whole file (what you posted is obviously not it, since there are tons of functions and variables used in the code you posted that are not defined in the code you posted), that's about as specific as I can get.

Grimsin 09-28-12 12:26 AM

hmm well im not so sure anymore that the targetframe is the initial taint culprit anymore but on the target frame note.. Yes i had thought about dumping the events before and you may have noticed my note to myself in the code that i made months ago to come back and hide the target frame the way you posted but i have two things that rely on the original target frame still functioning... at least to some degree. The target castbar and buffs :(

i suppose my hope at this point should be that i can leave the events necessary for those to function right intact and ditch the event thats causing it to try to hide/show the original? maybe a simple unregister of the petbattle start and finish events on the target frame? hmm but is the target frame even looking for such events? It did not look like it when i was going through it earlier.

Phanx 09-28-12 05:21 PM

Ignoring, for the moment, all of your current code and everything it does, what exactly do you actually want to do with the target frame?

Grimsin 09-28-12 06:13 PM

Well... everything is redone on the target frame in grimui. Buffs are separated between what you cast and what other friendly units cast and separated again between buffs and debuffs. So on the GrimUI target frame the buffs appear either to the right or left of the center of the top of the frame and buffs/debuffs you cast appear higher and slightly larger on the screen. Then there is the 3d model... and all the art work... and all that jazz.

In order for the buff stuff to work right i had to use some of the current blizz functions and it requires the original targetframes events to still be intact. Because all i really did was rearrange blizzards own buff icons and then position them where they needed to be for my target frame. I did the same thing with the enemy cast bar.

Also GrimUI gives the option to run both my window and the original window and allows the user to switch back and forth at will(out of combat of course... the options dont work at all in combat that would be silly).

Grimsin 09-28-12 08:17 PM

This is what the window looks like... its problem is when it hides in combat after a petbattle... before a petbattle works fine always has...

Phanx 09-29-12 10:37 PM

If you're not using the default target frame, why are you using the default target buff/debuff icons? Whatever addon you're using for your custom target frame should also be able to show buffs/debuffs, and likely a castbar. If not, there are plenty of standalone castbar addons that can show a target castbar, and writing a fully custom castbar isn't too hard.

What addon are you using for your custom target frame?

Grimsin 09-30-12 08:22 AM


Originally Posted by Phanx (Post 265396)
If you're not using the default target frame, why are you using the default target buff/debuff icons? Whatever addon you're using for your custom target frame should also be able to show buffs/debuffs, and likely a castbar. If not, there are plenty of standalone castbar addons that can show a target castbar, and writing a fully custom castbar isn't too hard.

What addon are you using for your custom target frame?

.... Thats my addon... its all my code... Its all part of GrimUI and GrimUI these days uses NO outside addons. Does not include Macaroon anymore even.

The problem is i was having trouble writing something for the buffs in fact i have problems any time it comes to buttons/icons. Like my threee problem areas are backpack space, buttons, and buffs lol. It was easier for me to adjust the blizz target buffs to my frame then anything else and until the pet battle stuff it worked fine.

The cast bar i may be able to replicate I have not tried to yet...

Side note: unregisterallevents on the blizz targetframe stops the taint... but i lose the buffs and the cast bar...

Phanx 09-30-12 08:35 PM

See PhanxBuffs for a very simple example of creating buff/debuff icons that don't depend on any other addons or libraries, and don't depend on any parts of the default UI being visible.

All times are GMT -6. The time now is 06:36 AM.

vBulletin © 2020, Jelsoft Enterprises Ltd
© 2004 - 2020 MMOUI