the way the wow client works, it maintains a local cache of items that it has seen to avoid having to fetch data from the server all the time. as you play and collect data, that cache fills up. occasionally (like with patches) that cache is reset and so you no longer have that data locally. GetItemInfo() returns the data in the local cache if it exists. if there's no data, it will query the server and return nil. some time later, the item data will become available. i'm not sure if there's an event for this data becoming available. GET_ITEM_INFO_RECEIVED might work, but i'm not 100% sure...
you should probably design your system such that a nil return is acceptable and just have a standin icon or something (like a "?") with the ability to update itself should data become available later.
Is see, thanks. Would there be any reason to name UI objects if they're only needed for the scope of one addon then, or would assigning names just be a waste of memory?
most people like to avoid littering the global namespace with stuff that's not needed. part of this is efficiency of the system, but i think mostly it's just to be tidy.
i tend to avoid giving widgets names as much as possible. sometimes, tho, you have to in order to make templates work properly (some blizz code will utililze the names internally -- it's always a good idea to look thru the blizz code of any template you're using just to make sure you know what's going on).
also, it supplants the function "getglobal()" if you happen to see it in any tutorials or how-tos.
basically, as phanx was saying, all global variables are accessible by name thru this table. its main use is to get at variables whose names are created on the fly.
for i=1,10 do
local actionButton = _G["MyCoolFrameActionButton"..i]
...
end
dunno how i missed that GetNormalTexture method, but the point wasn't necessarily to show how to access that specific item, but how to get at the various elements you might find in a template.
yes, you can change the tex coords. but like you mention, the trick is accessing the texture widget.
templated ui elements typically build multiple widgets. each widget is named based on the parent name with some identifier appended to it (like $parentNormalTexture). this means it's vital to pass a name to the widget you create with a template if you want to access its sub-elements. also, that name should be unique since it's in the global space.
so if you do:
[FONT=monospace]
[/FONT]local b = CreateFrame("CheckButton", "myAddonActionButton5", parentFrame, "ActionButtonTemplate")
then you can access the "NormalTexture" texture widget directly from its global handle:
local normalTexture = ["myAddonActionButton5NormalTexture"]
i think those are generally referred to as ActionButtons. the wow api has basic hard-coded widget classes (frames, buttons, fontstrings, sliders, textures, etc) and then there are a boatload of templates defined in xml/lua that utilize those basic widgets to provide an expanded toolset of ui elements. "button" is a widget, "ActionButton" is a template that has all the elements to make it look like your standard item button in the ui. you just need to fill in a few things (icon textures, for example) and it's done.
for the most part, you can use the standard widgets to get things done and then just hand code your own xml and/or lua to make things look and behave like some other ui element without touching one of the blizzard templates. one exception to this is what you're trying to accomplish. there's no way for non-secure lua to execute a protected function (like casting a spell or using an item). we addon authors only write non-secure lua, so we need to hook into secure blizzards secure code to handle these functions. this is where the secure template stuff comes into play.
at least, that's how i understand things to work...
what is FontGroup? how is it created? i see code that looks like it's maybe related to saved variables, but if FontGroup is a wow api widget, it won't save properly into a saved var file which means it will be nil when you load your addon.
basically, you'll want to create secure action button then set the attributes to determine what action you want. in this case, you'd probably want to run a macro that you have your addon create and/or edit to be:
/cast prospecting
/use [item in question]
but you could also define your button here to be an explicit item use or spell cast button without resorting to a macro creation.
i wouldn't put "OnUpdate" in there just because this could useful for other things you'd like to throttle (for example, BAG_UPDATE or other potentially fast-firing events).
the function "throttle" creates an anonymous function (at execution time?) that wraps up the function passed to "thottle" (your "OnUpdate" handler code) with basic throttling code. the newly created function is then returned and that function (with throttling code) is passed to the SetScript command.
...and then the old ones return and devour humanity... or something.
i think the idea of assigning a function to a script handler as a return from a called function that creates a new function using the function you passed is pretty clever and shows some of the power of lua, but man... i think you're going to cause some people to go into an endless loop and lose their minds! could you imagine trying to explain this to a new lua user? i think some of the more confusing aspects to programming come from function handles vs function calls and this one like a puzzle.
that aside, again, i think it's pretty clever and i might even use it myself, but please, hide this from the children!
one thing i might suggest to help people follow things is to maybe define throttle(func,interval) as something like THROTTLE_WRAPPER(trottledFunction, interval) so people will recognize immediately that it's special in some way.
thinking about it, this would be useful for event handlers as well.
This worked flawlessly when I played wow back in the BC. My next question is where could I find someone to hire to make this light addon a reality?
Would really love it to work like it did 2 years ago and not looking to make any type of gui, the hard coding is fine. But yea any advice on where I can hire someone to help me with this would be great!
Thanks
well, lua syntax hasn't changed, so the file must have since you last used it. if the lua parser is choking on it, it would have back in bc as well. fixing the mismatched if-end blocks would be the first step.
beyond that, you could add 'local this = CreateFrame("Frame")' to the top of your file to get your started down the road to making it run. it's horribly hacky, but i get that you just want something that runs and that (i think) would get you running (again assuming you sort out your syntax error(s)).
0
0
the way the wow client works, it maintains a local cache of items that it has seen to avoid having to fetch data from the server all the time. as you play and collect data, that cache fills up. occasionally (like with patches) that cache is reset and so you no longer have that data locally. GetItemInfo() returns the data in the local cache if it exists. if there's no data, it will query the server and return nil. some time later, the item data will become available. i'm not sure if there's an event for this data becoming available. GET_ITEM_INFO_RECEIVED might work, but i'm not 100% sure...
you should probably design your system such that a nil return is acceptable and just have a standin icon or something (like a "?") with the ability to update itself should data become available later.
0
most people like to avoid littering the global namespace with stuff that's not needed. part of this is efficiency of the system, but i think mostly it's just to be tidy.
i tend to avoid giving widgets names as much as possible. sometimes, tho, you have to in order to make templates work properly (some blizz code will utililze the names internally -- it's always a good idea to look thru the blizz code of any template you're using just to make sure you know what's going on).
0
basically, as phanx was saying, all global variables are accessible by name thru this table. its main use is to get at variables whose names are created on the fly.
for i=1,10 do local actionButton = _G["MyCoolFrameActionButton"..i] ... end0
dunno how i missed that GetNormalTexture method, but the point wasn't necessarily to show how to access that specific item, but how to get at the various elements you might find in a template.
0
templated ui elements typically build multiple widgets. each widget is named based on the parent name with some identifier appended to it (like $parentNormalTexture). this means it's vital to pass a name to the widget you create with a template if you want to access its sub-elements. also, that name should be unique since it's in the global space.
so if you do:
[FONT=monospace] [/FONT]local b = CreateFrame("CheckButton", "myAddonActionButton5", parentFrame, "ActionButtonTemplate")then you can access the "NormalTexture" texture widget directly from its global handle:
then you can do whatever you want with it...
0
for the most part, you can use the standard widgets to get things done and then just hand code your own xml and/or lua to make things look and behave like some other ui element without touching one of the blizzard templates. one exception to this is what you're trying to accomplish. there's no way for non-secure lua to execute a protected function (like casting a spell or using an item). we addon authors only write non-secure lua, so we need to hook into secure blizzards secure code to handle these functions. this is where the secure template stuff comes into play.
at least, that's how i understand things to work...
0
0
http://www.wowpedia.org/SecureActionButtonTemplate
basically, you'll want to create secure action button then set the attributes to determine what action you want. in this case, you'd probably want to run a macro that you have your addon create and/or edit to be:
/cast prospecting
/use [item in question]
but you could also define your button here to be an explicit item use or spell cast button without resorting to a macro creation.
0
err... yeah, duh.
0
maybe TrottledScriptFactory or something...?
0
0
...and then the old ones return and devour humanity... or something.
0
i think the idea of assigning a function to a script handler as a return from a called function that creates a new function using the function you passed is pretty clever and shows some of the power of lua, but man... i think you're going to cause some people to go into an endless loop and lose their minds! could you imagine trying to explain this to a new lua user? i think some of the more confusing aspects to programming come from function handles vs function calls and this one like a puzzle.
that aside, again, i think it's pretty clever and i might even use it myself, but please, hide this from the children!
one thing i might suggest to help people follow things is to maybe define throttle(func,interval) as something like THROTTLE_WRAPPER(trottledFunction, interval) so people will recognize immediately that it's special in some way.
thinking about it, this would be useful for event handlers as well.
0
well, lua syntax hasn't changed, so the file must have since you last used it. if the lua parser is choking on it, it would have back in bc as well. fixing the mismatched if-end blocks would be the first step.
beyond that, you could add 'local this = CreateFrame("Frame")' to the top of your file to get your started down the road to making it run. it's horribly hacky, but i get that you just want something that runs and that (i think) would get you running (again assuming you sort out your syntax error(s)).