Beta API discussion

[Haleth]

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:

local F, C, L = unpack(select(2, ...))
 
if C.general.buffreminder == false then return end
 
local class = select(2, UnitClass("Player"))
local buffs = C.selfbuffs[class]
 
if buffs and buffs[1] then
    local frame = CreateFrame("Frame", nil, UIParent)
    local a1, p, a2, x, y = unpack(C.unitframes.target)
    frame:SetPoint(a1, p, a2, x, y+90)
    frame:SetSize(57, 57)
    
    frame.icon = frame:CreateTexture(nil, "ARTWORK")
    frame.icon:SetTexCoord(.08, .92, .08, .92)
    frame.icon:SetAllPoints(frame)
    frame.icon:SetTexture("Interface\\Icons\\Spell_Holy_InnerFire")
    print(frame.icon:GetTexture()) -- returns texture
 
    F.CreateBG(frame)
 
    frame:Hide()
    
    frame:RegisterEvent("UNIT_AURA")
    frame:RegisterEvent("PLAYER_LOGIN")
    frame:RegisterEvent("PLAYER_REGEN_ENABLED")
    frame:RegisterEvent("PLAYER_REGEN_DISABLED")
    
    frame:SetScript("OnEvent", function(self, event)
        if (event == "PLAYER_LOGIN" or event == "LEARNED_SPELL_IN_TAB") then
            for i, buff in pairs(buffs) do
                local name = GetSpellInfo(buff)
                local usable, nomana = IsUsableSpell(name)
                if (usable or nomana) then
                    -- this makes no difference: frame.icon:SetTexture("Interface\\Icons\\Spell_Holy_InnerFire")
                    print(frame.icon:GetTexture()) -- returns nil
                    self.hasTexture = true
                    break
                end
            end
            if (not self.hasTexture and event == "PLAYER_LOGIN") then
                self:UnregisterAllEvents()
                self:RegisterEvent("LEARNED_SPELL_IN_TAB")
                return
            elseif (self.hasTexture and event == "LEARNED_SPELL_IN_TAB") then
                self:UnregisterAllEvents()
                self:RegisterEvent("UNIT_AURA")
                self:RegisterEvent("PLAYER_LOGIN")
                self:RegisterEvent("PLAYER_REGEN_ENABLED")
                self:RegisterEvent("PLAYER_REGEN_DISABLED")
            end
        end
        if (UnitAffectingCombat("player") and not UnitInVehicle("player")) then
            for i, buff in pairs(buffs) do
                local name = GetSpellInfo(buff)
                if (name and UnitBuff("player", name)) then
                    self:Hide()
                    return
                end
            end
            self:Show()
        else
            self:Hide()
        end
    end)
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]

Originally Posted by Meorawr 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]

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]

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]

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):

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]

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]

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:

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:

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]

Originally Posted by Xrystal 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]

Originally Posted by TSquared 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]

Originally Posted by Phanx 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]

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

[Meorawr]

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]

Originally Posted by Meorawr 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).

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

[Meorawr]

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]

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]

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.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]

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]

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:

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]

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

Because:

Originally Posted by TSquared 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

[Seerah]

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