XML / Frame Frame is a base type used as a fundamental UI building block for defining ' active ' visible screen elements . The Frame type can be used for Layout due to LayoutFrame , and a full set of Appearance and Behaviour facilities . Provides a base type for Button , EditBox , ScrollingMessageFrame , and many others . Inheritance . Inherited by : Button . . . , Inherits : LayoutFrame , Defined in : Frames , Ui , Runtime object : UIOBJECT _ Frame Summary . Frame based elements facilitate ' Layout ' , ' Appearance ' and ' Behaviour ' mechanisms for the WoW UI at runtime . When used with « a href = " XML / Scripts " > Scripts < / a » along with the « a href = " XML / Anchors " > Anchors < / a » and the < Size > element from LayoutFrame , allows WoW to ' Layout ' all of its visible and make them interactive and responsive , including the 3D views of the world . Frame works by providing a flexible set of layout and scripting constructs . Frames also provide a sophisicated ' Z order ' based layering system , both in « a href = " XML / Layers " > Layers < / a » element and between the frames themselves . Example . « a href = " XML / Frame " > Frame < / a > name = " MyFrameTemplate " hidden = " true " virtual = " true " / > This example will align the top of the ' child ' frame to the top of ' MyFrame ' , and then offset that alignment by - 22 vertically . Also demonstrates use of Dimension with Size and Anchor , and using Abs and inline values , as well as use of ' $ parent ' to specify the name of the child where the child ' name ' will be ' MyFrameChild ' at runtime . Finally this example shows use of ' inherits ' and ' virtual ' where ' MyFrameTemplate ' is inherited by ' MyFrame ' causing ' MyFrame ' to inherit ' hidden ' from ' MyFrameTemplate ' making ' MyFrame ' hidden by default . At runtime , you can refer to the child frame as either MyFrameChild or MyFrame . child . Details . Description . Frames are the building blocks of the visual components of the user interface . All of the various visual elements of the UI are types of Frame , and inherit most if not all of the basic frame properties , in addition to adding some more . Frames are defined in the various . xml files in the Interface directory ( except for the Bindings . xml files , which provide key bindings ) . Events . In addition to Frames being the things that you can see , Frames are also the things which UI and game events are delivered to . If you ' re writing code that needs to know about something , it will need a Frame ( though not necessarily a visible one ) to receive the event . There are many types of events , though often in AddOn development it refers to a Game Event rather than other UI events . A frame indicates its interest in events in a number of ways : UI Interaction . The < Scripts > XML element of a frame definition defines a bunch of different handler types , for most of these ( < OnEvent > being the exception ) the Frame will automatically be informed of the appropriate events when they occur , via the defined handler script . Game Interaction . Most of the useful information comes from game events , which are all passed to the frame via the generic < OnEvent > script handler . There are literally hundreds of types of Game Events , so rather than spend a lot of time passing every event to every handler , an AddOn must register its interest in a frame receiving a certain event . This is accomplished through the Frame : RegisterEvent ( " event " ) function , and is typically performed within the < OnLoad > or < OnShow > handlers . Once an event has been registered , the Frame ' s < OnEvent > handler will be called whenever that event occurs . Virtual Frames . Frames , like all LayoutFrame types , can be defined as virtual , in which case instead of defining an actual UI element that shows up , the definition provides a template which can then be used multiple times by other Frames . A good example of a virtual Frame is the chat window , there are actually several virtual frames which are assembled into a chat window , but then each potential chat window simply implements the virtual one , which reduces the amount of duplicated code required . Parents . Frames have a parent frame . A complex visual element is likely formed of multiple Frames , and it ' s considered good design to designate a common parent Frame amongst them , and have the rest use that ( or its children ) as their parent . Well behaved UI AddOns will normally want their top level parent frames set expressly to ' UIParent ' . Failure to do so means , amongst other things , that the AddOn ' s frame won ' t vanish when the Hide UI key is pressed . Visibility . Each Frame can be shown and hidden , if a Frame is Hidden , then it and all of its children cease to be visible . It ' s far simpler to show and hide the parent frame of a complex set , than to try and manage the visibility of many elements independently . Scaling . The UI engine is built to perform automatic scaling of UI elements , the entire UI ( actually , the UIParent frame , which most frames are children of ) , or any component of it can be enlarged or shrunk to fit on a screen appropriately . Frames are scaled and located relative to their parent rather than the whole screen , which means that you only need to worry about how your subcomponents relate to each other , and then your component can be placed and sized any way necessary . Frame Levels . Frame levels are that which determines what frame will be on top of other frame . Each frame has a frame level value . If frame A is placed in the same area as frame B , then the frame with the highest frame level will be on top of the other frame . Instead of going around and specifying that frame A should have frame level 12 , and frame B frame level 15 , Blizzard uses a set of predefined " groups " of frame levels called frameStrata . The valid values for frameStrata are " PARENT " , " BACKGROUND " , " LOW " , " MEDIUM " , " HIGH " , " DIALOG " , " FULLSCREEN _ DIALOG " and " TOOLTIP " ( there may be more ) . For the values " BACKGROUND " through " TOOLTIP " the values are listed in their assumed ascendancy ( i . e . it is assumed that " BACKGROUND " will be below " LOW " ) . The default value is " PARENT " if no frameStrata is specified . There is also a special attribute called toplevel - this means ( hopefully ) that the frame should be on top of any other frame ( or , possibly , on top of any other frame in the same frameStrata ) . frameLevel and frameStrata . Well first off , though you can set frameLevel in your < Frame > tag , frameLevel is dictated by XML nesting . Check this example out : Since UIParent ' s frameLevel is 1 , the frame we created here should be frameLevel 2 and the Button should be frameLevel 3 . You can check a frame ' s level with Frame : GetFrameLevel ( ) and you can set it with Frame : SetFrameLevel ( ) . However , setting a frame ' s level is ill - advised . It is given its level automatically and it ' s best to leave it that way . If you need to change a frame ' s level in your own code , best thing to do is just nest your code differently . Note : If the parent of a frame is changed by your code , the frame levels are not adjusted to compensate . You may need to adjust the frame ' s level to fix the way the frame displays . The maximum value seems to be 129 . If you call SetFrameLevel with a value greater than 129 , the value passed will be ignored , and the frame level will be set to 129 . In my experimentation , and with my WoW client ( Windows ) , it seems higher values will stick , and be honored , if you call SetFrameLevel twice in a row . This is probably unreliable . If you find that you are having to set frame levels greater than 129 , see if you can use a hierarchical set of parent frames instead . A more complete explanation of how frame levels are used is found at How the user interface is rendered .