As I have commented on the Talk:World of Warcraft API page, I actually like this page. I will review the method list here to make sure that everything is on here, but I actually think we should go ahead with this page.
A couple of questions for Flickering, or more like a discussion starter, just so that I understand your method:
- How are you obtaining the list of functions for each widget?
What I do is this: I have a UI AddOn that has in its .xml one of each possible widget defined. In-game I run a Lua script that checks, based on a large list of candidates extracted from WoW.exe, the existence of methods on each of the widgets. Is this the same as what you are doing?
- How are you deciding on what widget is derived from what?
I had two sources for this: UI.xsd that defines the relationship of the XML elements, and educated guesswork based on what methods the different widgets share. The UI.xsd route is not unambiguous though, as the Lua API inheritance isn't necessarily linked to the XML hierarchy. What were you basing your hierarchy on?
Lego 19:26, 6 Feb 2005 (EST)
I also have question about a few particular methods, GetAlpha, SetAlpha and SetScale.
With regards to GetAlpha, I have noticed that you removed it from LayoutFrame and you added it to Frame and Texture instead, since FontString doesn't support it. I guess this is possible, I originally had GetAlpha under LayoutFrame for the sake of symmetry (with a warning under FontString), but I agree that your presentation is perhaps less confusing. So let's keep it your way.
With regards to SetAlpha and SetScale, I noticed you have them under Model too. Is this on purpose i.e. are these functionally different than the Frame ones, or did they just accidentally get in there?
One last point: I have a nice analysis script that if you are interested in, I am happy to share. The scanning of method functions on widgets in-game produces for me a very long list, with lots of repeated entries, since many mehods are common to many objects (e.g. Frame:Show, Button:Show, Texture:Show). What my analysis script does is look at this dump from the in-game and makes intelligent guesses as to the inheritance relationship between the widgets, with a little input from the user, and eliminates the unnecessary entries accordingly. This is how I generated the original Widget API list in the first place. I still have this script lying around, on the off-chance that Blizzard significantly updates the Widget API, which I doubt.
Lego 19:41, 6 Feb 2005 (EST)
How I created this list
I'll be able to answer both of your questions if I describe the process by which I created this list. It's done in a similar manner to the main API scan, but with some obvious differences related to the nature of methods, and to try and determine the inheritance tree.
Scanning
- I scan all of the .xml files in FrameXML and build a map of element name to frame type. This then gets encoded into a LUA table for the symbol scanner to use.
- I scan the executable for anything that looks like it may be a valid method name (I did scan over the original list to make sure that none of them contained numbers, etc - I may repeat the process some day with a less filtered set). This gets encoded into a LUA table as well.
- I load these into an addon and then execute it in game, basically it scans each potential frame, ensures the symbol is defined and a table, then it tests every possible method name to see if type(element[symbolName]) == 'function'. If so then it records the element, it's type, the method name, and the function ID (See next step)
- In order to try and keep track of inheritance, when I see a function for a given symbol, I look through all of the functions I've ever seen for that same symbol and generate an ID such that if two objects have the same function for the same method (compared using the lua == operator) then they will get the same ID for that function, and if they have different functions then they have different ID's.
- All of this data gets dumped into a SavedVariable, then digested into XML afterwards
Analysis
- First I checked that every element of the same type had the exact same methods, they did - so it simplified other things. (This step actually happens during scan so that I can keep the amount of saved variable space used down, but it's easier to describe here).
- Next I determined an inheritance tree such that would satisfy the following basic rule:
- A class either inherits or overrides each of its superclass' methods, it can never 'drop' a method.
- I artifically override the 'LayoutFrame' methods since they are actually different functions for the different root nodes, but they do seem to behave the same in all cases (Unlike AddMessage, which appears to have different arguments in its 2 incarnations)
- I also artifically added MovieFrame since it's not in the FrameXML UI - I just copied what was in the wiki.
- Finally the analysis script builds a derivation tree and outputs this tree into wiki format (with comments and arguments grabbed from another file (Which I created initially from the main API page)).
The result is the page you see here, and blizzard's code completely obeys the derivation rule I was using, so it dropped out pretty cleanly. (The first version of this page you saw was before I added the LayoutFrame override).
GetAlpha() is one level lower than LayoutFrame because including it would break my inheritance derivation rule (I did consider taking the approach from the original API page, but I felt that removing a method was too confusing). I did consider creating an AlphaLayoutFrame which was LayoutFrame + GetAlpha() but that seemed like it would be excessive.
Model has its own SetAlpha() and SetScale() methods because they are different functions from the parent element. If we identify that they behave identically then I can add an additional override to the script so it'll ignore them.
The argument information was hand-selected based on a combination of the existing Wiki documentation, the results of my code and symbol analyser (see http://www.vigilance-committee.org/wow/downloads/ - the 4150-merged-v2.zip file, for the raw output of that), and inspection of actual FrameXML code.
-- Flickering 23:34, 6 Feb 2005 (EST)
Impressive
I have read your explanation, impressive. For example, I never thought of using the actual values of the functions and doing comparisons between them to see if they are the same or not. Anyway looks like you have done a very thorough job of analysing the methods, more so than I did. Keep it up. :-) Thanks for the explanations, that answers all my questions and I have learnt something.
[Bah, I always forget to put this at the end:] Lego 20:10, 7 Feb 2005 (EST)
Latest Patch (1.2.4)
I have checked the list on patch 1.2.3, didn't see any changes. (Presumably Lego) <- that is correct, it was me, just forgot to sign, as usual. Lego 07:17, 16 Feb 2005 (EST)
I checked against the US 4211 patch and also see no changes to the Widget API. -- Flickering 16:45, 15 Feb 2005 (EST)
Verified for EU 1.2.4 -- Lego 06:40, 25 Feb 2005 (EST)
Types versus Objects
It's important to remember that this page is documenting the functions available on each TYPE of XML object.. i.e. Minimap refers to all objects declared as
<Minimap ...>
And not to the object with the global name Minimap (in this case they're the same). I've removed the following two misplaced links because they're referring to methods on Button objects called MinimapZoomIn and MinimapZoomOut, not to widget types.
- MinimapZoomIn:(Enable/Disable) - Enables or disables the zoom in button on the minimap.
- MinimapZoomOut:(Enable/Disable) - Enables or disables the zoom out button on the minimap.
If anyone wishes to make a list of all of the standard UI elements, their names, types, and useful messages, then a new page would be the appropriate place for it, but this page is not.
-- Flickering 18:59, 2 Jun 2005 (EDT)
Does this stuff work ?
A lot of this stuff doesn't seem to work. For example all the Model methods.
Are there any examples of Widget API stuff being used for us slowbies ? :)
GameTooltip
I removed this entry, since it's a handler not a function and so belongs somewhere else (I'm not sure where)
- GameTooltip:OnTooltipAddMoney(money) - Called when the amount and coin graphics are added to the tooltip text
I didn't know where either. This seemed like the only logical place for it. -- Greenman
- I moved it to UIHANDLER OnTooltipAddMoney where it belongs. --Mikk 01:42, 7 August 2006 (EDT)
Secure Frames
I just added a new category for the post-2.0 secure frames. For now I declared them as UI Objects, since they each require unique treatment by the programmer who uses them. The actual sub articles for the different frames should probably contain some information on how to handle them, i.e. valid attributes and what they do. --DerGhulbus 20:47, 6 February 2007
Registered Events
Is there any way to get a list of all frames, iterate through them, and see what events are registered to them? Failing that, is there a way to get a list of all frames, iterate through them and blindly unregister an event? Egingell 08:17, 15 July 2007 (UTC)
- EnumerateFrames()... and no there is no way to poll what events a frame has registered. What exactly are your intending to hack away at? User:Tekkub/Sig 08:43, 16 July 2007 (UTC)