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:
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. |
Quote:
|
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* |
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. |
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) TL;DR: Use _G[x], not getglobal(x). |
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. |
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! Code:
local t = UIParent:CreateTexture(nil, "OVERLAY"); |
Quote:
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. |
Quote:
|
Quote:
|
It's such an easy fix, so why leave an inefficient alternative just for the sake of backwards compatibility?
|
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. |
Quote:
Arguably, though, something is 'broken' when there is a much more efficient way to do it, as is the case with _G. |
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. |
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.
|
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. |
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. |
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) |
Quote:
Quote:
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 |
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