WoWInterface

WoWInterface (https://www.wowinterface.com/forums/index.php)
-   MoP Beta archived threads (https://www.wowinterface.com/forums/forumdisplay.php?f=162)
-   -   Beta API discussion (https://www.wowinterface.com/forums/showthread.php?t=43091)

Haleth 07-04-12 06:34 AM

Zork; That also sets the texture but still returns nil.

I've looked at it some further and it seems to be some sort of problem with OnEvent. This is my modified code with a few tests in it:

Lua Code:
  1. local F, C, L = unpack(select(2, ...))
  2.  
  3. if C.general.buffreminder == false then return end
  4.  
  5. local class = select(2, UnitClass("Player"))
  6. local buffs = C.selfbuffs[class]
  7.  
  8. if buffs and buffs[1] then
  9.     local frame = CreateFrame("Frame", nil, UIParent)
  10.     local a1, p, a2, x, y = unpack(C.unitframes.target)
  11.     frame:SetPoint(a1, p, a2, x, y+90)
  12.     frame:SetSize(57, 57)
  13.    
  14.     frame.icon = frame:CreateTexture(nil, "ARTWORK")
  15.     frame.icon:SetTexCoord(.08, .92, .08, .92)
  16.     frame.icon:SetAllPoints(frame)
  17.     frame.icon:SetTexture("Interface\\Icons\\Spell_Holy_InnerFire")
  18.     print(frame.icon:GetTexture()) -- returns texture
  19.  
  20.     F.CreateBG(frame)
  21.  
  22.     frame:Hide()
  23.    
  24.     frame:RegisterEvent("UNIT_AURA")
  25.     frame:RegisterEvent("PLAYER_LOGIN")
  26.     frame:RegisterEvent("PLAYER_REGEN_ENABLED")
  27.     frame:RegisterEvent("PLAYER_REGEN_DISABLED")
  28.    
  29.     frame:SetScript("OnEvent", function(self, event)
  30.         if (event == "PLAYER_LOGIN" or event == "LEARNED_SPELL_IN_TAB") then
  31.             for i, buff in pairs(buffs) do
  32.                 local name = GetSpellInfo(buff)
  33.                 local usable, nomana = IsUsableSpell(name)
  34.                 if (usable or nomana) then
  35.                     -- this makes no difference: frame.icon:SetTexture("Interface\\Icons\\Spell_Holy_InnerFire")
  36.                     print(frame.icon:GetTexture()) -- returns nil
  37.                     self.hasTexture = true
  38.                     break
  39.                 end
  40.             end
  41.             if (not self.hasTexture and event == "PLAYER_LOGIN") then
  42.                 self:UnregisterAllEvents()
  43.                 self:RegisterEvent("LEARNED_SPELL_IN_TAB")
  44.                 return
  45.             elseif (self.hasTexture and event == "LEARNED_SPELL_IN_TAB") then
  46.                 self:UnregisterAllEvents()
  47.                 self:RegisterEvent("UNIT_AURA")
  48.                 self:RegisterEvent("PLAYER_LOGIN")
  49.                 self:RegisterEvent("PLAYER_REGEN_ENABLED")
  50.                 self:RegisterEvent("PLAYER_REGEN_DISABLED")
  51.             end
  52.         end
  53.         if (UnitAffectingCombat("player") and not UnitInVehicle("player")) then
  54.             for i, buff in pairs(buffs) do
  55.                 local name = GetSpellInfo(buff)
  56.                 if (name and UnitBuff("player", name)) then
  57.                     self:Hide()
  58.                     return
  59.                 end
  60.             end
  61.             self:Show()
  62.         else
  63.             self:Hide()
  64.         end
  65.     end)
  66. end

Setting the texture on frame.icon, then calling GetTexture(), returns the texture. However, calling GetTexture in the OnEvent code returns nil - whether or not I set the texture again, there.

I've added a boolean hasTexture to work around the GetTexture() problem, but it's very strange.

Xrystal 07-04-12 06:54 AM

Quote:

Originally Posted by Meorawr (Post 257615)
getglobal is deprecated in favour of _G, however the function still exists.

Thanks, thought I'd better double check while I'm in the process of updating my addons. I try not to use it if I can but best to be somewhat future proof.

Sockz0r 07-04-12 10:35 AM

VehicleMenuBarPitchUpButton ==> OverrideActionBarPitchFramePitchUpButton -- pitch up vehicle button
VehicleMenuBarPitchDownButton ==> OverrideActionBarPitchFramePitchDownButton -- pitch down vehicle button
VehicleMenuBarLeaveButton ==> OverrideActionBarLeaveFrameLeaveButton -- leave vehicle button

the textures for them are a bit buggy though *shrug*

Gragagrogog 07-04-12 05:19 PM

name, type, difficultyIndex, difficultyName, maxPlayers, playerDifficulty, isDynamicInstance = GetInstanceInfo()

difficultyIndex is different from live... seems like its always -1 from live but i tested only SW and 5man normal tolvir dungeon.

Phanx 07-04-12 06:49 PM

getglobal has been deprecated for years. It was actually removed from the game for a while -- and there are dozens, if not hundreds, of posts on these forums asking for help updating old addons that were throwing nil values because of getglobal usage -- though it looks like Blizzard has re-added a Lua implemention of it for some reason. Despite its reapparance, there is no reason you should ever use it. It's a function call, so it's automatically slower and more expensive than a table lookup. Plus, with it implemented in Lua (in UIParent.lua):

Code:

function getglobal(varr)
    return _G[varr];
end

It's even more inefficient because it's still doing the table lookup you should be doing, but it's also adding a Lua function call. Huge waste, and Blizzard should be embarrassed to have such bloated, inefficient crap in their code.

TL;DR: Use _G[x], not getglobal(x).

Xrystal 07-04-12 08:15 PM

Thanks Phanx,

I remembered reading it somewhere in one of the patch notes in the past but I lost track of which way round it was being deprecated so my addons are a mixture of using _G and getglobal at the moment depending on when they were updated last and what my memory of it was at the time .. so yep, another set of changes to incorporate.

Meorawr 07-06-12 05:33 AM

As we're on the subject of texture issues, I've noticed that setting a texture's BlendMode to ALPHAKEY or DISABLE seems to crash the client with an assertion error. Something to keep in mind if you're using those modes (for whatever reason).

Same failure for both modes:
Code:

ERROR #0 (0x85100000) Assertion failure!

Program:        D:\Games\World of Warcraft Mists of Pandaria Beta\WoW-64.exe
ProcessID:        1448
File:        CSimpleRender.cpp
Line:        3355
Expr:        !"Caller should really do this"

Test case:
Code:

local t = UIParent:CreateTexture(nil, "OVERLAY");
t:SetAllPoints(UIParent);
t:SetTexture([[Interface\Buttons\WHITE8X8]]);
-- Below line crashes client if mode == ALPHAKEY or DISABLE. Other modes are fine.
t:SetBlendMode("ALPHAKEY");


TSquared 07-06-12 10:44 AM

Quote:

Originally Posted by Xrystal (Post 257658)
Thanks Phanx,

I remembered reading it somewhere in one of the patch notes in the past but I lost track of which way round it was being deprecated so my addons are a mixture of using _G and getglobal at the moment depending on when they were updated last and what my memory of it was at the time .. so yep, another set of changes to incorporate.


The getglobal() is there so that old addons won't get arbitrarily busted. While there is a small over-head to using it, it's probably not noticeable in most addons. Considering it used to thunk into C it *has* to be faster than that.

Phanx 07-06-12 05:27 PM

Quote:

Originally Posted by TSquared (Post 257754)
The getglobal() is there so that old addons won't get arbitrarily busted. While there is a small over-head to using it, it's probably not noticeable in most addons. Considering it used to thunk into C it *has* to be faster than that.

But it was gone for so long... how can there possibly be any addons at this point that haven't been updated? And if an addon hasn't been updated in 3-4 years, it's probably best to let it stay dead, since it obviously does not have an active author? :(

Voyager 07-06-12 05:31 PM

Quote:

Originally Posted by Phanx (Post 257774)
But it was gone for so long... how can there possibly be any addons at this point that haven't been updated? And if an addon hasn't been updated in 3-4 years, it's probably best to let it stay dead, since it obviously does not have an active author? :(

Recount still uses getglobal(), there are probably many more active addons using it.

Talyrius 07-06-12 05:39 PM

It's such an easy fix, so why leave an inefficient alternative just for the sake of backwards compatibility?

Meorawr 07-06-12 05:47 PM

Why break what isn't broken?

Not that I'm condoning getglobal's usage, but the presence of the function is a pretty minor issue so long as developers know that _G does just the same as it in every regard, and I'm sure most of the resources which mention the very existence of the function make this pretty clear in some way.

Haleth 07-06-12 05:54 PM

Quote:

Originally Posted by Meorawr (Post 257781)
Why break what isn't broken?

I wonder this often when it comes to Blizzard's logic of renaming certain stuff (e.g. ShapeshiftBarFrame -> StanceBarFrame). :p

Arguably, though, something is 'broken' when there is a much more efficient way to do it, as is the case with _G.

Meorawr 07-06-12 06:05 PM

Supporting backwards compatibility for getglobal compared to ignoring compatibility for something like actionbars is a bit different though - for example, the behaviour of the bars might have changed in a significant enough way to merit a breaking change as a way of saying 'WAKEY WAKEY AUTHORS RISE AND SHINE' :)

Of course if it were just a straight up rename, then you're right and they're odd. Perhaps poking them gently with sticks would be warranted in that situation.

Talyrius 07-06-12 06:12 PM

If they don't remove getglobal() then many ignorant addon authors will continue to make use of it simply because they don't know any better or have been too lazy to make the change.

Meorawr 07-06-12 06:30 PM

It staying or going doesn't affect me or any addons I've worked on, so I'm completely indifferent to the matter.

On the one hand I do agree it should be eradicated off the face of UIParent.lua, especially now during an expansion patch, but I'm still of the mindset of "why break what isn't broken"; a somewhat distant example of this would be the Win32 API 'A' functions still existing, but being mostly useless and there for backwards compatibility (as far as I know they're just wrappers around the unicode versions).

As for not knowing any better, I'd imagine that's only true for those who stumbled upon getglobal by accident. Both Wowprogramming and Wowpedia list the functions as being equivalent to _G, and they're both somewhat 'useful' for any author as far as API references go :).

I still don't think there's really a strong enough reason to outright remove it. Performance-wise you're only adding in function call overhead which isn't completely FPS killing to begin with, and a ridiculously lazy author could just shove a copy of the getglobal function at the top of his files, completely negating the benefits of _G.

And yes, I know I said I don't care about the function, I don't, but I don't really sound like I don't, do I? :p

P.S. I love this conversation. It's much more interesting than copying Blizzard's HelpPlate system for my own sick, twisted and vile uses.

Fizzlemizz 07-06-12 07:16 PM

When I picked up DUF (an addon born in the early days of WOW) in December it was still using get/setglobal. Mind you, along with getting it working this was one of the first changes I made once I found out these calls were deprecated at some stage.

That said, it was my first plunge into LUA and misunderstandings lead to starting over a couple of times. It would have been a royal pain to be forced to make however many dozens of these changes up front each time.

Talyrius 07-06-12 08:55 PM

Blizzard breaks API on a regular basis (more-so with expansions). I fail to understand the rationale behind continuing to make getglobal() an exception to this.

If Blizzard removed it, you would get the following error:
Code:

attempt to call global "getglobal" (a nil value)
After a quick Google search, you would discover that function was deprecated and what method should be used in its place. Any addon author is capable of this—novice or otherwise.

Meorawr 07-06-12 09:06 PM

Quote:

Originally Posted by Talyrius (Post 257803)
I fail to understand the rationale behind continuing to make getglobal() an exception to this.

Because:

Quote:

Originally Posted by TSquared (Post 257754)
The getglobal() is there so that old addons won't get arbitrarily busted. While there is a small over-head to using it, it's probably not noticeable in most addons.

It's just a matter of not breaking things for the sake of breaking things, the difference between this and API changes is that API changes happen out of necessity (the vast majority of the time, at least) and maintaining backwards compatibility there is a lot harder.

It's a three line function, the only benefit from removing it is any addons using it won't be subject to function call overhead. The downsides are that any addons which do use it, regardless of why, will be broken. Downsides outweigh the upsides, and that's what I'd wager the rationale is behind the decision.

Of course they could change their mind after they see this discussion, who knows :p

Seerah 07-06-12 09:38 PM

Guys, I think that's enough with the getglobal rants/speculations. Back on topic before I delete all of it. :p


All times are GMT -6. The time now is 10:33 PM.

vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI