"Load" is slightly misleading, but sure. If you embed them into your addon table, you can call the methods through it. If you don't embed them or want a reference to a single library's API, you get a new reference to it using LibStub.
You're gonna have to be more helpful.. you're not really addressing most of the points presented here. Put some effort into addressing all suggestions made here, explaining what you've tried, actually try some stuff. Just replying to everything with "Doesn't work" won't get us anywhere.
Consider a resolution of 4x4. Also consider a texture with dimensions 3x2. If you place the texture using the horisontal center (TOP, BOTTOM or CENTER) it's going to go between pixels, so to speak. Since the width is an odd value, the middle of the texture is the middle of a pixel, not between pixels, which the center of the screen is, and so it won't match up. WoW won't automatically adjust stuff to the pixel grid or anything. The texture will be drawn starting from 0.5 pixels from the left, ending at 3.5 pixels. Hope that clears it up!
You can use :GetLeft(), :GetRight() etc on the texture to get the position relative to the screen.
Make sure everything is positioned exactly according to the screen's pixels. If the border is placed x.5 pixels from the edge for example, that will cause a blur. This is common when you're dealing with stuff with dimensions of odd numbers and/or using CENTER for anchoring.
Depending on what you want to do, you could also just use a frame with a backdrop. Use the solid texture (don't know which one it is off the top of my head) for bg and edge, and just set the colors.
If what you want is something like a system for creating unit frame headers in which you can create unit frames, here's a simple example which utilises metatables:
local headerPrototype = {}
local headerMT = {__index = headerPrototype}
local headers = {}
local function createHeader(headerName)
local header = {} -- could be a frame instead if needed
setmetatable(header, headerMT)
headers[headerName]
header.unitframes = {}
return header
end
local unitframePrototype = {}
local unitframeMT = {__index = headerPrototype}
function headerPrototype:CreateUnitFrame(unit)
local unitframe = CreateFrame("Frame")
setmetatable(unitframe, unitframeMT)
self.unitframes[unit] = unitframe
return unitframe
end
function unitframePrototype:CreateHealthBar()
local healthbar = CreateFrame("StatusBar")
self.healthbar = healthbar
return healthbar
end
-- now you can create stuff like this:
local partyFrame = createHeader("party")
local unitframe1 = partyFrame:CreateUnitFrame("party1")
local healthbar1 = unitframe1:CreateHealthBar()
Not trying to be mean or anything, but it feels like you're mostly guessing how to use tables ("objects") and metatables and do not really understand how they work. Am I wrong? Edit: Alrite I missed a few things. UnitFrame.__index = UnitFrame works but you'll probably want to separate different object methods into different metatables, otherwise you'll be able to create unit frames in unit frames for example, since the unit frame objects now inherit all methods.
I don't really understand what you want help with either. You can definitely use some nice OOP-style programming. Let's start over; can you describe briefly what, exactly, it is that you want to do/achieve?
Regarding hiding variables; yes, you should use local variables wherever possible.
for id, profession in pairs(ProfTable) do
profession.plugin = LibStub("LibDataBroker-1.1"):NewDataObject("TheIOSLibTest"..id, {
This part is hard for me to visualize but let's try?
ProfTable[profession] = 1 (on the first run, 2 on the second run, etc).
This feels wrong. I just can't read that line I guess.
profession.plugin becomes the LibStub frame/object named "TheIOSLibTest1" then "TheIOSLibTest2" and so on.
Now where or how is the addon figuring out what profession equals on the first run, as opposed to the /reload run.
We haven't told it that profession = ProfTable[id] until a piece that can only be accurate the second time we run it?
Just so we're on the same page here; you are confused as to how the 'profession' variable can have the value that it does, in that code? If no, disregard this. If yes; it's more simple than you think. Imagine a numeric for loop, like you already have:
for id = 1, #ProfTable do
local profession = ProfTable[id]
end
Each entry in the table is represented by an index (or key) and the value at that index. In this numeric for loop, the variable 'id' holds the index of each entry, in each iteration of the loop. The first time the loop runs, id is 1, then each iteration the value of 'id' increments by 1 until the limit of #ProfTable (6?) is reached. The 'profession' variable gets assigned the value of the table entry at index 'id' for each iteration.
All that the pairs function does is it automatically assigns the index and the value to the variables that you provide ('id' and 'profession'), and also makes sure to stop at the end of the table.
Now I think this has probably been mentioned in the thread, but pairs is not necessarily the same as ipairs of the numeric for-loop in that it can be used with tables whose keys are not sequential integers starting from 1. ipairs or a numeric for-loop cannot be used for such tables, but since yours is sequentially indexed (I think?), you can forget about that for now. When used for sequential tables, pairs works the same as ipairs, which really is the same as a numeric for-loop.
for id = 1, #ProfTable do
local profession = ProfTable[id]
end
for id, profession in ipairs(ProfTable) do
-- profession is merely an automatically created variable assigned the value of ProfTable[id]
-- you could do local profession = ProfTable[id] here too if you wanted, and it would work, but ipairs has already done this for you
end
For all intents and purposes, the second example does internally what you do yourself in the first example.
A quick look at the recently updated addons on Curseforge seems to indicate that they're all manual uploads, so yeahhh.. WoWAce seems unaffected however.
Is something wrong now? SVN server seems down or something. Commit fails with:
Error: Commit failed (details follow):
Error: Unable to connect to a repository at URL
Error: 'svn://svn.curseforge.net/wow/vortex/mainline/trunk'
timed out
Edit: Guess it's technically not related to the packager.
0
0
0
http://wowpedia.org/CVar_UIFaster
Something they implemented ages ago. Not sure if these issues today are the same.
0
0
0
0
You can use :GetLeft(), :GetRight() etc on the texture to get the position relative to the screen.
0
0
0
0
This may or may not be a practical way to do it.
0
Edit: Alrite I missed a few things. UnitFrame.__index = UnitFrame works but you'll probably want to separate different object methods into different metatables, otherwise you'll be able to create unit frames in unit frames for example, since the unit frame objects now inherit all methods.
I don't really understand what you want help with either. You can definitely use some nice OOP-style programming. Let's start over; can you describe briefly what, exactly, it is that you want to do/achieve?
Regarding hiding variables; yes, you should use local variables wherever possible.
0
Just so we're on the same page here; you are confused as to how the 'profession' variable can have the value that it does, in that code? If no, disregard this. If yes; it's more simple than you think. Imagine a numeric for loop, like you already have:
Each entry in the table is represented by an index (or key) and the value at that index. In this numeric for loop, the variable 'id' holds the index of each entry, in each iteration of the loop. The first time the loop runs, id is 1, then each iteration the value of 'id' increments by 1 until the limit of #ProfTable (6?) is reached. The 'profession' variable gets assigned the value of the table entry at index 'id' for each iteration.
All that the pairs function does is it automatically assigns the index and the value to the variables that you provide ('id' and 'profession'), and also makes sure to stop at the end of the table.
Now I think this has probably been mentioned in the thread, but pairs is not necessarily the same as ipairs of the numeric for-loop in that it can be used with tables whose keys are not sequential integers starting from 1. ipairs or a numeric for-loop cannot be used for such tables, but since yours is sequentially indexed (I think?), you can forget about that for now. When used for sequential tables, pairs works the same as ipairs, which really is the same as a numeric for-loop.
For all intents and purposes, the second example does internally what you do yourself in the first example.
Hope it helps!
0
0
Error: Commit failed (details follow):
Error: Unable to connect to a repository at URL
Error: 'svn://svn.curseforge.net/wow/vortex/mainline/trunk'
timed out
Edit: Guess it's technically not related to the packager.