WoWInterface - View Single Post - Just trying to revive an old add... need a little help
View Single Post
04-12-20, 02:19 AM   #7
nUI Maintainer
Xrystal's Avatar
Premium Member
AddOn Author - Click to view addons
Join Date: Feb 2006
Posts: 5,510
Thumbs up

Originally Posted by TransformedBG View Post

I noticed your template had the function as a local function.... is that needed? if i leave it like that i get the nil value error...
Hmm, it should work fine as a local function. By the time your own function is accessing it, it should be in the files local environment and accessible to it.
You are duplicating some areas .. You have your GLUA global table which has its own frame which has an event watcher .. so rather than call the event watch function I gave you as a template you can just use your own event watcher function.

Lua Code:
  1. GLUA = {}
  2. GLUA.GLUA_Frame = CreateFrame("Frame")
  3. GLUA.GLUA_Frame:RegisterEvent("ADDON_LOADED")
  5. GLUA.GLUA_Frame:RegisterEvent("PLAYER_LEVEL_UP")
  6. GLUA.GLUA_Frame:RegisterEvent("CHAT_MSG_GUILD")
  7. GLUA.GLUA_Frame:RegisterEvent("GUILD_ROSTER_UPDATE")
  9. GLUA.GLUA_Frame:SetScript("OnEvent", function(self,event,...)--EventWatcher)
  10.       .. put the code inside EventWatcher in here
  11. end)

Also, as a side note. Unless you want other addons to use GLUA in their own addons you can make GLUA either local or a part of the addonData table which is just for your addons.

The following is why I use local and addon wide values and rarely use globals.

If you don't have these functions as local functions you could break addons that have similar names in their *global* function names and you could be overriding their functionality with yours.

If the functionality/data is only needed in the file local is the best situation.
If the functionality/data is needed across your whole addon and you want more manageable files you can split your files up and have different types of functionality stored in different files and all share the same data.

EG. Translation Files

This could be your enUS translate file
Lua Code:
  1. local addonName,addonData = ...
  2. addonData.Locale = GetLocale()
  3. addonData.Translate =
  4. {
  5.       ["Translate Key 1"] = "Translate Value in this locales language"
  6. }

This would be one of your foreign languages
Lua Code:
  1. local addonName,addonData = ...
  2. if ( addonData.Locale == "frFR" ) then    
  3.     addonData.Translate = {
  4.       ["Translate Key 1"] = "Translate Value in this locales language"
  5.     }
  6. end

Just rinse and repeat your supported languages with your chosen default as the main translation file and any supported in additional files.

The addonData.Locale is set in the main translation file and is accessible in all files loaded after.

Your main code then only has to call addonData.Translate["Translate Key 1"] for this example and it will automatically pick the correct language for the user if it is supported or fall back to the default language.

This multi file system relies on loading order to work properly so you will have to identify which files need to be loaded before another one so that any functions/values etc are in the addons memory before they are called.

So to reiterate...

You have global values/functions that are accessible by any addon and could inadvertently override another addons functionality or break it altogether.

You have addon wide values/functions that are accessible by the addon it is placed in. Think of it as local to your addon rather than local to a file/function etc.

You have local values/functions that are only available in the confines of the code blocks they are used in. Either a file wide local value or a function wide local value or even a loop wide local value.

Local values are always your best option if you only want that block of code to access it.

Addon wide values are your next best option if you want those values accessible amongst multiple files in a bigger or more manageable addon.

Global values should only be used if you intend to override a functionality in another addon or blizzards own functionality. Bear in mind that unless these were intended to be overridden you may have unintended problems.

For example:
In my latest addon project I intend to have global functions with unique names that will allow other addons to be plugins to my addon project to modify certain elements.

So I would have a bunch of *untouchable* local or addon wide functionality and then a global function say for example :
Lua Code:
  1. function Xrystal_Override<Module>(data)  
  2. {
  3. .. code to replace default module data with customised module data ..  
  4. }
And the other addon would be able to set up their module data and then call the Xrystal_Override<Module>(...) passing in the data table they created for that module as follows:
Lua Code:
  1. local displayData = { ... }
  2. Xrystal_OverrideDisplay(displayData)

This could be used for example to allow users of your addon to create translation plugins to your addon that will be accessible by your addon via their addon registering their data for your addons use. Or to replace the layout of your addons default UI with one that think would work better for themselves and other people.

Last edited by Xrystal : 04-12-20 at 02:27 AM.
  Reply With Quote