Mana/Power level

[AlleyKat]

like this:

[Seerah]

I'm sorry, are you requesting something? Or...

[humfras]

Nice idea. If you want a tip on how to do this, see below:

Create the background texture (the scale) and a (square) texture for the indicator.
Create a ScrollFrame (like in the Questlog) with the size of the background texture (e.g. ScrollFrame:SetAllPoints(background)) and create the indicator texture as a child of the ScrollFrame.
The indicator will be visible in the ScrollFrame area only.

[zork]

Actually you can do sth like this easily with the animation system or by just rotating a texture. Just think of the accelerometer as a circle and the needle is a texture that you rotate around the center of that circle. That and using texture alpha layers properly. To rotate a texture without the animation system around its center you can do:

--needle texture rotate
  local texture = frame:CreateTexture(nil,"BACKGROUND",nil,-6)
  texture:SetTexture(PATH_TO_TEXTURE)
  texture:SetSize(sqrt(2)*frame:GetWidth(),sqrt(2)*frame:GetHeight())
  texture:SetPoint("CENTER")
  texture:SetRotation(math.rad(30))

Using a texture alpha layer you can show/hide whatever part of the background.

If you need to crop stuff...just use a ScrollFrame. ScrollFrames crop any content inside.
http://www.wowinterface.com/forums/s...ad.php?t=45810

[AlleyKat]

Originally Posted by humfras Nice idea. If you want a tip on how to do this, see below: Create the background texture (the scale) and a (square) texture for the indicator. Create a ScrollFrame (like in the Questlog) with the size of the background texture (e.g. ScrollFrame:SetAllPoints(background)) and create the indicator texture as a child of the ScrollFrame. The indicator will be visible in the ScrollFrame area only.

too hard lol.
I like this way:

local holder = CreateFrame("ScrollFrame", "Holder", UIParent); -- holder
holder:SetSize(w, h);
holder:SetPoint(...);
 
local parent = CreateFrame("Frame", "Parent", holder) -- parent of our elements
holder:SetScrollChild(parent);
 
local anytexture = parent:CreateTexture(...);
anytexture:SetPoint(..., holder, ...); -- point to holder, not to parent
 
...

[pelf]

Sorry, I couldn't hear that code over the sound of Holder and Parent being added to (or having their values replaced in) the global environment.

[AlleyKat]

Originally Posted by pelf Sorry, I couldn't hear that code over the sound of Holder and Parent being added to (or having their values replaced in) the global environment.

this is example

local title, M = ...;
local holder = CreateFrame("ScrollFrame", title.."Holder", UIParent);

[Phanx]

That's better, but there's really no reason to give your frame a global name at all, unless you're using a Blizzard template that requires a name.

local holder = CreateFrame("ScrollFrame", nil, UIParent)

[AlleyKat]

Originally Posted by Phanx That's better, but there's really no reason to give your frame a global name at all, unless you're using a Blizzard template that requires a name. local holder = CreateFrame("ScrollFrame", nil, UIParent)

I like to give names for static frames, you can easily access via plugins and it costs almost nothing in memory usage.

[Phanx]

Well, for one, what is the likelihood that anyone is actually going to write a plugin for a simple mana display addon? I'd have to go with the probability of that being pretty much zero.

For another, you don't need to give everything a global name in order for it to be accessible. Give your main object a global name, and add references to everything else to it as table members:

local mainFrame = CreateFrame("Frame", "MyAddon", UIParent)

local otherFrame = CreateFrame("Button", nil, mainFrame)
mainFrame.Button = otherFrame

-- now other addons can access "otherFrame" as "MyAddon.Button"

[AlleyKat]

Originally Posted by Phanx Well, for one, what is the likelihood that anyone is actually going to write a plugin for a simple mana display addon? I'd have to go with the probability of that being pretty much zero. For another, you don't need to give everything a global name in order for it to be accessible. Give your main object a global name, and add references to everything else to it as table members: local mainFrame = CreateFrame("Frame", "MyAddon", UIParent) local otherFrame = CreateFrame("Button", nil, mainFrame) mainFrame.Button = otherFrame -- now other addons can access "otherFrame" as "MyAddon.Button"

Frames must have names for framestack function and OnUpdate/OnEvent tracking.
You can drop textures and fontstrings names, but, i think, you must keep frame`s name.

[Resike]

Originally Posted by AlleyKat Frames must have names for framestack function and OnUpdate/OnEvent tracking. You can drop textures and fontstrings names, but, i think, you must keep frame`s name.

Frames don't have names, they can have a global reference, which means other addons can use/change that frame too. And if a frame has a global reference then you will see that name as the frames name.

[AlleyKat]

Originally Posted by Resike Frames don't have names, they can have a global reference, which means other addons can use/change that frame too. And if a frame has a global reference then you will see that name as the frames name.

That s Blizzard problem, thas why i use addon title before frame name, to protect random global variable.
And i don`t care about memory, lua has a lot of memory leaks with table rehash and everyone run game in 64bit mode.

[AlleyKat]

Originally Posted by zork Actually you can do sth like this easily with the animation system or by just rotating a texture. Just think of the accelerometer as a circle and the needle is a texture that you rotate around the center of that circle. That and using texture alpha layers properly.

first steps, looks funny
http://www.youtube.com/watch?v=wA-Qspt7W-U

[Resike]

Originally Posted by AlleyKat That s Blizzard problem, thas why i use addon title before frame name, to protect random global variable. And i don`t care about memory, lua has a lot of memory leaks with table rehash and everyone run game in 64bit mode.

It's still going to be global. You just merging the string's name which is going to be the global reference's "name".

[AlleyKat]

Originally Posted by Resike It's still going to be global. You just merging the string's name which is going to be the global reference's "name".

This is not good? It slows down system?

[Resike]

Originally Posted by AlleyKat This is not good? It slows down system?

No but it's pointless if you don't need it as a global too, and could cause taints, if it's not named properly.

If you use it like this:

local holder = CreateFrame("ScrollFrame", "holder", UIParent)

Then it's overwrites your local holder, aka it becomes global, and then you can reach that variable sligtly slower. That can slow down your functions, since it takes more time to find that var.

[Vrul]

Originally Posted by Resike If you use it like this: local holder = CreateFrame("ScrollFrame", "holder", UIParent) Then it's overwrites your local holder, aka it becomes global, and then you can reach that variable slightly slower. That can slow down your functions, since it takes more time to find that var.

That would not overwrite the local. There would be both a local and a global reference, with the local superseding the global. Also, any "slow down" would be negligible outside of an OnUpdate script or an extremely frequently called OnEvent handler.

I'm all for advocating less pollution of _G but not at the expense of misinformation.

[AlleyKat]

Originally Posted by Resike No but it's pointless if you don't need it as a global too, and could cause taints, if it's not named properly. If you use it like this: local holder = CreateFrame("ScrollFrame", "holder", UIParent) Then it's overwrites your local holder, aka it becomes global, and then you can reach that variable sligtly slower. That can slow down your functions, since it takes more time to find that var.

It is not pointless, frame is like base of your ui elements and it must has name.
There are two types of variables: local and upvalue, if you are anonced local variable, you no longer can get upvalue from function environment, only via direct call from env table, like _G.
to avoid tains and etc you can put addon name before frame name

[Resike]

Originally Posted by Vrul That would not overwrite the local. There would be both a local and a global reference, with the local superseding the global. Also, any "slow down" would be negligible outside of an OnUpdate script or an extremely frequently called OnEvent handler. I'm all for advocating less pollution of _G but not at the expense of misinformation.

I still had some issues with the code above.