Questions About Manipulating SetPoint()

Clamsoda · 06-26-13, 08:47 PM

Good evening,

I wanted to start by making an inquiry:

Is it considered acceptable practice to destroy an object's SetPoint() function, similar to:

Lua Code:

someProperlyNamedFrame.SetPoint = function() end

I have a strange feeling that this is a good way to taint the UI or some such.

I have also tried to safely manipulate SetPoint as such:

Lua Code:

hooksecurefunc(someProperlyNamedFrame, "SetPoint", function(self) 
    self:SetPoint(stuff here obviously) 
end)

This actually worked, but BugSack reports a C stack overflow, whatever that is.

Any insight about such processes would be much appreciated.

Thanks!

Dridzt · 06-26-13, 08:57 PM

Second example is a circular reference, since every :SetPoint() run on that frame re-triggers the securehook ad-infinitum

Clamsoda · 06-26-13, 09:01 PM

Oh, that makes sense. Thank you.

Nibelheim · 06-26-13, 09:02 PM

Originally Posted by Clamsoda

Is it considered acceptable practice to destroy an object's SetPoint() function, similar to:

Lua Code:

someProperlyNamedFrame.SetPoint = function() end

I have a strange feeling that this is a good way to taint the UI or some such.

It does cause taint. How bad the results of said taint will depend on the frame you used it on. Someone with more taint knowledge may be able to weigh in on this better.

I have also tried to safely manipulate SetPoint as such:

Lua Code:

hooksecurefunc(someProperlyNamedFrame, "SetPoint", function(self) 
    self:SetPoint(stuff here obviously) 
end)

As mentioned below, this is a circular doohicky. Can be prevented like so:

Lua Code:

local PointGettingSet
hooksecurefunc(someProperlyNamedFrame, "SetPoint", function(self)
    if PointGettingSet then return end
    PointGettingSet = true
    -- do stuff here
    self:SetPoint(stuff here obviously) 
    PointGettingSet = false
end)

Clamsoda · 06-26-13, 09:05 PM

Lua Code:

local PointGettingSet
hooksecurefunc(someProperlyNamedFrame, "SetPoint", function(self)
    if PointGettingSet then return end
    PointGettingSet = true
    -- do stuff here
    self:SetPoint(stuff here obviously) 
    PointGettingSet = false
end)

Oh, that is neat. I thought it would still trigger the secure hook over and over, but I am seeing now that it would only respond to the SetPoint calls.

semlar · 06-26-13, 10:09 PM

Actually all you have to do is create a separate reference to the frame's SetPoint function and call that instead of what you hooked.

Lua Code:

local oSetPoint = f.SetPoint
hooksecurefunc(f, 'SetPoint', function(self)
    self:ClearAllPoints()
    oSetPoint(self, 'CENTER')
end)

You will also need to clear its previous points or you could run into unexpected behavior.

Nibelheim · 06-26-13, 10:20 PM

Originally Posted by semlar

Actually all you have to do is create a separate reference to the frame's SetPoint function and call that instead of what you hooked.

Lua Code:

local oSetPoint = f.SetPoint
hooksecurefunc(f, 'SetPoint', function(self)
    self:ClearAllPoints()
    oSetPoint(self, 'CENTER')
end)

Ohh, clever

Clamsoda · 06-27-13, 08:30 AM

Originally Posted by semlar

Actually all you have to do is create a separate reference to the frame's SetPoint function and call that instead of what you hooked.

Lua Code:

local oSetPoint = f.SetPoint
hooksecurefunc(f, 'SetPoint', function(self)
    self:ClearAllPoints()
    oSetPoint(self, 'CENTER')
end)

Fantastic =]. Working perfectly! Thank you very much for the response.

SDPhantom · 06-27-13, 10:09 AM

Originally Posted by semlar

Lua Code:

local oSetPoint = f.SetPoint
hooksecurefunc(f, 'SetPoint', function(self)
    self:ClearAllPoints()
    oSetPoint(self, 'CENTER')
end)

You will also need to clear its previous points or you could run into unexpected behavior.

Ideally, this should be done before the call that runs the hook. Otherwise, you break the ability to have a frame dynamically resize via 2 or more points.

Additionally, you're not necessarily destroying the original function. All methods of a frame reside in a metatable shared amongst all other frames of the same type. If for whatever reason, you want to restore the frame to its original functionality, you can just set the entry in the table back to nil. Understanding metatables can get tricky, but they are powerful if you know how they work.

semlar · 06-27-13, 01:37 PM

Originally Posted by SDPhantom

Ideally, this should be done before the call that runs the hook. Otherwise, you break the ability to have a frame dynamically resize via 2 or more points.

You can set however many points you need to after clearing them.

Lua Code:

local oSetPoint = f.SetPoint
hooksecurefunc(f, 'SetPoint', function(self)
    self:ClearAllPoints()
    oSetPoint(self, 'TOPLEFT', -4, 4)
    oSetPoint(self, 'BOTTOMRIGHT', 4, -4)
end)

SDPhantom · 07-01-13, 03:24 AM

It just seems like a waste of CPU power to not only block normal calls to frame:SetPoint(), which should be enough by itself, but to clear and redefine the frame's points. What I would suggest is setting the frame's points before disabling the frame:SetPoint() metamethod on said frame.

Code:

frame:SetPoint(<<Frame Point Data>>);
frame.SetPoint=function() end;--	Usually a nil value in the frame's table itself

Remember, when you try to access a table field that has a nil value, Lua falls back to the __index field of its metatable if one exists.

Clamsoda · 07-01-13, 03:39 AM

Well, that is what I was doing, SDPhantom. My inquiry was to how detrimental it is to void a frame's SetPoint function; and if there was a healthier alternative.

If there is no downside to the practice, then that is what I would continue to use.

semlar · 07-01-13, 09:26 AM

Replacing the SetPoint function of a frame will taint it, so if that matters for what you're doing, don't do it.

I don't know if the taint log has been fixed, but previously it would cause actual lua errors (or even crashed the game) if it detected certain execution paths had been tainted and logging had been enabled.

If this is not for a blizzard frame, then there's no downside to replacing the function, otherwise it's generally best practice to avoid tainting the execution path because it can easily cause unforeseen consequences.

Depending on what you're trying to accomplish it's sometimes possible to avoid calling the function in the first place (and still avoiding taint) by unregistering the events that trigger it and reproducing some of the code yourself.

SDPhantom · 07-01-13, 01:14 PM

Originally Posted by Clamsoda

Well, that is what I was doing, SDPhantom. My inquiry was to how detrimental it is to void a frame's SetPoint function; and if there was a healthier alternative.

If there is no downside to the practice, then that is what I would continue to use.

As far as taint, sure, the dummy function will taint the execution path for any code that runs it. There is no other problem with diverting the calls to your dummy function. As I've explained before, you're not necessarily wiping out the original function entirely. You're just adding a function into the frame's table in such a way it'll use that function rather than indexing its metatable. Anyone can still access the original function by going through the metatable. For example, getmetatable(frame).__index.SetPoint() will access the original function regardless of what you did to the frame's table. Note you'll have to add in the frame itself as the first argument since it's a different way of calling the function than most are used to, but it'll still work.

Clamsoda · 07-01-13, 05:27 PM

Originally Posted by semlar

Replacing the SetPoint function of a frame will taint it, so if that matters for what you're doing, don't do it.

Well, I guess it will take some time to see how large of an impact my meddling will have.

Originally Posted by semlar

If this is not for a blizzard frame, then there's no downside to replacing the function, otherwise it's generally best practice to avoid tainting the execution path because it can easily cause unforeseen consequences.

Well, it is for a LOT of Blizzard frames, specifically the ContainerFrame#Slot# frames.

Originally Posted by SDPhantom

As far as taint, sure, the dummy function will taint the execution path for any code that runs it. There is no other problem with diverting the calls to your dummy function. As I've explained before, you're not necessarily wiping out the original function entirely. You're just adding a function into the frame's table in such a way it'll use that function rather than indexing its metatable. Anyone can still access the original function by going through the metatable. For example, getmetatable(frame).__index.SetPoint() will access the original function regardless of what you did to the frame's table. Note you'll have to add in the frame itself as the first argument since it's a different way of calling the function than most are used to, but it'll still work.

Well, in light of such a comprehensive post, I think that I will stick to the dummy function method for now, and see what sort of impact is has down the line. I have been playing while using this method for a while now, and it hasn't produced any headache.

Thanks for all of the insight and explanations, especially regarding meta....stuff

zork · 07-02-13, 01:46 AM

Try the dummy function in combat first. If it fails (aka spits out a taint) stop right there. It will get you nothing.

Clamsoda · 07-02-13, 02:15 AM

Originally Posted by zork

Try the dummy function in combat first. If it fails (aka spits out a taint) stop right there. It will get you nothing.

Well, it has made it past that! Thanks for the reply Zork!