Runes of Magic Wiki
Explore
Main Page
All Pages
Interactive Maps
navigation
Main Page
Recent changes
Community portal
Random page
Admin noticeboard
wiki navigation
Classes
Equipment
Regions and Cities
Quests
Bestiary
Gathering
Processing
Production
Sitemap
Transmutation Chart
Attributes
portals
Runes of Magic
Joint RoM Forum
Official Games Status
RoM Discord Servers
Unofficial Server Status 1
Unofficial Server Status 2
Unofficial Server Status 3
Twitch
RoM-Welten database
Wikia RoM Wiki
Wikidot RoM Wiki
ZAM RoM Wiki
Gamepedia
Gamepedia support
Report a bad ad
Help Wiki
Contact us
FANDOM
Fan Central
BETA
Games
Anime
Movies
TV
Video
Wikis
Explore Wikis
Community Central
Start a Wiki
Don't have an account?
Register
Sign In
Sign In
Register
Runes of Magic Wiki
27,506
pages
Explore
Main Page
All Pages
Interactive Maps
navigation
Main Page
Recent changes
Community portal
Random page
Admin noticeboard
wiki navigation
Classes
Equipment
Regions and Cities
Quests
Bestiary
Gathering
Processing
Production
Sitemap
Transmutation Chart
Attributes
portals
Runes of Magic
Joint RoM Forum
Official Games Status
RoM Discord Servers
Unofficial Server Status 1
Unofficial Server Status 2
Unofficial Server Status 3
Twitch
RoM-Welten database
Wikia RoM Wiki
Wikidot RoM Wiki
ZAM RoM Wiki
Gamepedia
Gamepedia support
Report a bad ad
Help Wiki
Contact us
Editing
Guide to Dynamic Frames
(section)
Back to page
Edit
VisualEditor
View history
Talk (0)
Edit Page
Guide to Dynamic Frames
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Stopping Global Pollution == One of the main problems with creating frames via XML is that all frames and their sub-elements are created in the global namespace. Not only does this make accessing these frames slower, but it also creates an enormous global namespace. Last time I checked (back in version 3.0.4 or so), the _G table contained well over 60000 entries. This will slow access down even more since the Lua virtual machine much slog through this table for each global variable accessed (well OK, due to how Lua works, it doesn't need to search all 60000 entries but it still slows it down). To make matters worse, each time we create a frame or frame element using <code>CreateUIComponent</code>, the game also creates a global variable with the same name as the element name provided. This constant use of global variables is known as polluting the global namespace. When we create frames dynamically, we have an opportunity to stop this effect. The way we do this is to ensure that we always assign the objects we create to a local variable or at least to some other object or table that will be a single point of access from global namespace. As our example add-on already has such a table, we can set our frame in there, as well as all sub-objects. Though if you've been paying attention, you will notice that all sub-objects are already being set inside the main frame's object. So all we need to do is set the base frame into our namespace variable, and remove all the global variables created by <code>CreateUIComponent</code>. So first, add the following two lines immediately after creating the base frame. <code><pre> _G.MemViewerDyn_Frame = nil; -- Remove global created by CreateUIComponent MemViewerDyn.Frame = MemViewerDynFrame; -- Save a reference for global access </pre></code> It is safe to <code>nil</code> the global in this fashion since there is still another reference to the object within our file (namely the local <code>MemViewerDynFrame</code>). We can now do the same for all the sub-elements we crete as well. For each call to <code>CreateUIComponent</code>, add a line to nil the global that it creates. Remember to use the name given in the call itself and not the name of the variable. It is also a good idea to place the <code>_G</code> here to ensure it is the global reference that is being removed. The three lines will be (to be placed after each corresponding call to <code>CreateUIComponent</code>): <code><pre> _G.MemViewerDyn_Text = nil; </pre></code> <code><pre> _G.MemViewerDyn_Texture = nil; </pre></code> <code><pre> _G.MemViewerDyn_Close = nil; </pre></code> In the case of the close button, because we are using a template, we should also ensure that any sub-objects created in the template is also removed from global space where appropriate. This is not required for this template so no other changes need be done for our code. However, some sub-elements created by templates may still need to reside in global space for the predefined functions to work correctly, so handle templates with care. Once the changes are done, try the new version. You will notice that the add-on runs fine, but if you close the window you will now need to type '''/run MemViewerDyn.Frame:Show()''' in the chat edit box to get it back. If you parse this last version of out example add-on, you will see that only one global variable (<code>MemViewerDyn</code>) is visible yet the entire add-on works as before.
Summary:
Please note that all contributions to the Runes of Magic Wiki are considered to be released under the CC BY-NC-SA
Cancel
Editing help
(opens in new window)
Follow on IG
TikTok
Join Fan Lab