Posting some code for ideas on

[Sieben11]

Fairly basic container code I made. Posting here if anyone has ideas. Or if I need to add/change something. It just makes a button that enables or hides a attached frame. The code to embed other data is not done. Have not figured how I was going to set that up. So all this provides is just what was mentioned before. It wasn't meant to be complex. So do understand that changes must be reflective of simplicity and/or I made a goof and you know a better way. Posting here because people here seem very helpful and nice.

To tell you the use I will be having for it. Will be for an add-on I am making for druids. It will monitor and watch for druid specific things like spells(dps/heal),forms etc. And the following code will be used as a container for these items. To representing them in fairly visual bars.

---
NAME: Define a unique name for the frames, most likely just addon name. To call the container in another frame use [add-on name] with "_Frame". As in "MyAddon_Frame".

ATTACH: Simple attach to frame.

STATE: Toggle initial state of container.

FWIDTH: Frame width.

FHEIGHT: Frame height.

BWIDTH: Button width.

BHEIGHT: Button height.

POINT: Point.

RELPOINT: Relative Point.
---

---
May extend for textures and child containers. IE a collapse container inside another collapse container.
---

Function:

function collapse_container(name,attach,state,fwidth,fheight,bwidth,bheight,point,relpoint)

local f = CreateFrame("Frame", name.."_Frame", attach)
f:SetFrameStrata("DIALOG")
f:RegisterForDrag("LeftButton")
f:SetMovable(true)
f:EnableMouse(true)
f:SetBackdrop({bgFile = "Interface/Tooltips/UI-Tooltip-Background", 
     edgeFile = "Interface/Tooltips/UI-Tooltip-Border", 
     tile = true, tileSize = 16, edgeSize = 16, 
     insets = { left = 4, right = 4, top = 4, bottom = 4 }})
f:SetBackdropColor(0,0,0,1)
f:SetClampedToScreen(true)
f:SetPoint(point, attach, relpoint) f:SetSize(fwidth,fheight)

f:SetScript("OnDragStart", f.StartMoving)
f:SetScript("OnDragStop", f.StopMovingOrSizing)

if state == true then f:Show()
else f:Hide()
end

local btn = CreateFrame("Button", name.."_Button", attach)
btn:SetFrameStrata("TOOLTIP")
btn:SetNormalTexture("Interface\\CHATFRAME\\UI-ChatIcon-Minimize-Up.blp")
btn:SetPushedTexture("Interface\\CHATFRAME\\UI-ChatIcon-Minimize-Down.blp")
btn:RegisterForClicks("LeftButtonUp")
btn:SetAlpha(0.2)
btn:SetClampedToScreen(true)
btn:SetPoint("TOPLEFT",f,"TOPLEFT",-25,0) btn:SetSize(bwidth,bheight) -- set to f

btn:SetScript("OnClick", function()
if state == true then
--show f, lock btn to 1 alpha
state = false
f:Hide()
btn:SetAlpha(1)
return
--
elseif state == false then
--hide f, keep showing btn
state = true
f:Show()
end
end)
btn:SetScript("OnEnter", function(self) if state == false then self:SetAlpha(1) end end)
btn:SetScript("OnLeave", function(self) if state == false then self:SetAlpha(0.2) end end)

end

Example:

collapse_container("My_Addon",UIParent,false,100,100,28,28,"CENTER","CENTER")

[Phanx]

Don't use DIALOG or TOOLTIP strata for things that are not dialogs or tooltips unless you have a very good reason. For all other cases, you should just parent frames appropriately, and they will automatically appear on the correct strata. If you "need" strange parenting for some reason, put both x and y on the same strata and use y:SetFrameLevel(x:GetFrameLevel() + 1) to fix the layering.

For boolean values, you can just do "if x then y else z end" instead of "if x == true then y elseif x == false then z end".

You initially set the button to 20% alpha. When it's clicked, you set the alpha to 100% when you hide the frame, but when you show the frame again you don't set the button back to 20% alpha. I'm assuming this is why you added the OnEnter and OnLeave scripts, but you can get rid of those if you just do btn:SetAlpha(0.2) when you do f:Show() in the OnClick script.

If that function is intended to be in the global namespace -- eg. not local, and not a table member like MyAddon:collapse_container() -- you should give it a more descriptive name that clearly identifies which addon it belongs to, like MyAddon_CollapseContainer.

You should add a check to prevent the function from creating frames for the same object more than once.

Finally, your code will be a lot easier to read and maintain if you use consistent indentation, spacing between comma-separated items, line breaks, and consistent naming practices (variables are lowercase, function and object names are camelcase, etc.).

function MyAddon_CollapseContainer(name, attach, state, fwidth, fheight, bwidth, bheight, point, relpoint)
	if not attach.containerFrame then
		local f = CreateFrame("Frame", name.."_Frame", attach)
		f:SetPoint("CENTER", attach, "CENTER")
		f:SetSize(100, 100)
		attach.containerFrame = f

		f:SetBackdrop({
			bgFile = "Interface/Tooltips/UI-Tooltip-Background", 
			edgeFile = "Interface/Tooltips/UI-Tooltip-Border", 
			tile = true, tileSize = 16, edgeSize = 16, 
			insets = { left = 4, right = 4, top = 4, bottom = 4 }
		})
		f:SetBackdropColor(0, 0, 0, 1)

		f:EnableMouse(true)
		f:SetMovable(true)
		f:SetClampedToScreen(true)
		f:RegisterForDrag("LeftButton")
		f:SetScript("OnDragStart", f.StartMoving)
		f:SetScript("OnDragStop", f.StopMovingOrSizing)

		local btn = CreateFrame("Button", name.."_Button", attach)
		btn:SetFrameLevel(f:GetFrameLevel() + 1)
		btn:SetPoint("TOPLEFT", f, -25, 0)
		btn:SetSize(28, 28)
		btn:SetAlpha(0.2)
		attach.containerButton = btn

		btn:SetNormalTexture("Interface\\CHATFRAME\\UI-ChatIcon-Minimize-Up")
		btn:SetPushedTexture("Interface\\CHATFRAME\\UI-ChatIcon-Minimize-Down")

		btn.state = state
		btn:RegisterForClicks("LeftButtonUp")
		btn:SetScript("OnClick", function(self, mouseButtonClicked)
			if self.state then
				--show f, lock btn to 1 alpha
				self.state = false
				f:Hide()
				btn:SetAlpha(1)
			else
				--hide f, keep showing btn
				self.state = true
				f:Show()
				btn:SetAlpha(0.2)
			end
		end)
	end

	if state then
		attach.containerFrame:Show()
	else
		attach.containerFrame:Hide()
	end
end

Also, I don't see anything in your code that's actually attaching the object to be contained to the container, so when you move/collapse the container, the object itself is unaffected. Have you actually tried to use this code, or are you just throwing out a drycoded idea?

[Sieben11]

Originally Posted by Phanx Don't use DIALOG or TOOLTIP strata for things that are not dialogs or tooltips unless you have a very good reason. For all other cases, you should just parent frames appropriately, and they will automatically appear on the correct strata. If you "need" strange parenting for some reason, put both x and y on the same strata and use y:SetFrameLevel(x:GetFrameLevel() + 1) to fix the layering. For boolean values, you can just do "if x then y else z end" instead of "if x == true then y elseif x == false then z end". You initially set the button to 20% alpha. When it's clicked, you set the alpha to 100% when you hide the frame, but when you show the frame again you don't set the button back to 20% alpha. I'm assuming this is why you added the OnEnter and OnLeave scripts, but you can get rid of those if you just do btn:SetAlpha(0.2) when you do f:Show() in the OnClick script. If that function is intended to be in the global namespace -- eg. not local, and not a table member like MyAddon:collapse_container() -- you should give it a more descriptive name that clearly identifies which addon it belongs to, like MyAddon_CollapseContainer. You should add a check to prevent the function from creating frames for the same object more than once. Finally, your code will be a lot easier to read and maintain if you use consistent indentation, spacing between comma-separated items, line breaks, and consistent naming practices (variables are lowercase, function and object names are camelcase, etc.). function MyAddon_CollapseContainer(name, attach, state, fwidth, fheight, bwidth, bheight, point, relpoint) if not attach.containerFrame then local f = CreateFrame("Frame", name.."_Frame", attach) f:SetPoint("CENTER", attach, "CENTER") f:SetSize(100, 100) attach.containerFrame = f f:SetBackdrop({ bgFile = "Interface/Tooltips/UI-Tooltip-Background", edgeFile = "Interface/Tooltips/UI-Tooltip-Border", tile = true, tileSize = 16, edgeSize = 16, insets = { left = 4, right = 4, top = 4, bottom = 4 } }) f:SetBackdropColor(0, 0, 0, 1) f:EnableMouse(true) f:SetMovable(true) f:SetClampedToScreen(true) f:RegisterForDrag("LeftButton") f:SetScript("OnDragStart", f.StartMoving) f:SetScript("OnDragStop", f.StopMovingOrSizing) local btn = CreateFrame("Button", name.."_Button", attach) btn:SetFrameLevel(f:GetFrameLevel() + 1) btn:SetPoint("TOPLEFT", f, -25, 0) btn:SetSize(28, 28) btn:SetAlpha(0.2) attach.containerButton = btn btn:SetNormalTexture("Interface\\CHATFRAME\\UI-ChatIcon-Minimize-Up") btn:SetPushedTexture("Interface\\CHATFRAME\\UI-ChatIcon-Minimize-Down") btn.state = state btn:RegisterForClicks("LeftButtonUp") btn:SetScript("OnClick", function(self, mouseButtonClicked) if self.state then --show f, lock btn to 1 alpha self.state = false f:Hide() btn:SetAlpha(1) else --hide f, keep showing btn self.state = true f:Show() btn:SetAlpha(0.2) end end) end if state then attach.containerFrame:Show() else attach.containerFrame:Hide() end end Also, I don't see anything in your code that's actually attaching the object to be contained to the container, so when you move/collapse the container, the object itself is unaffected. Have you actually tried to use this code, or are you just throwing out a drycoded idea?

---
I have highlighted things you mentioned that I found more useful in orange.
---

Don't use DIALOG or TOOLTIP strata for things that are not dialogs or tooltips unless you have a very good reason.

The button is part of the tooltip. Though it is not the tooltip. Hence the DIALOG for the button and TOOLTIP for the frame. I want the button at the very top without stepping over a tooltip. And from what I saw those 2 were the highest stratas. So DIALOG keeps the button topmost without stepping over TOOLTIP. Then will allow TOOLTIP to show over it.

The add-on will be using top level to ensure its information is above everything else. So would have been silly for me to include a strata underneath it. It was done to work with what I am doing. Its going to be a customized buff/debuff,form etc tooltip. So I'd figure tooltip strata works for a customized tooltip.

If you "need" strange parenting for some reason, put both x and y on the same strata and use y:SetFrameLevel(x:GetFrameLevel() + 1) to fix the layering.

Will try this out.

And however the containers are called puts them on a layer different then the others. Why I didn't bother setting anything. It was already doing it on its owns, and met my needs. Still will play with the above.

For boolean values, you can just do "if x then y else z end" instead of "if x == true then y elseif x == false then z end".

Yes a bool check can be done over ==. Though when I initially write, like a rough draft. I do not write those in. Given many times when I am working I'll often lose my place if i do them. Maybe I'm silly but I use == in rough. When the idea works as intended then I change them respectively.

Also, I don't see anything in your code that's actually attaching the object to be contained to the container, so when you move/collapse the container, the object itself is unaffected. Have you actually tried to use this code, or are you just throwing out a drycoded idea?

The above comment noted that I had not figured what to do with the actual part beyond the container. I have added more to it, though did not update that here. Basically this was just a container without applicable data. Though it could be easily made. Also to test use attach to attach to what you want it to work with. 2 containers fashioned this way. The parent will control the childs show/hide behavior. As for data that'll eventually come later on. And yes it works in game.

You initially set the button to 20% alpha. When it's clicked, you set the alpha to 100% when you hide the frame, but when you show the frame again you don't set the button back to 20% alpha. I'm assuming this is why you added the OnEnter and OnLeave scripts, but you can get rid of those if you just do btn:SetAlpha(0.2) when you do f:Show() in the OnClick script.

Differences:
mine > container button is faded on load, mouseover provides a fade in, mouseleave provides a fade out, clicking the button enforces alpha to stay regardless of mouseover/mouseleave. This way button only keeps its alpha when the frame is expanded.

yours > Initial state of container button is faded regardless of mouseover or mouseleave. Even when clicked the button stays faded and not locked to 1 alpha. Then when clicked again it sets 1 alpha and hides the frame. Later clicks provide : button at full alpha when frame is not shown. Then faded when it is.

If that function is intended to be in the global namespace -- eg. not local, and not a table member like MyAddon:collapse_container() -- you should give it a more descriptive name that clearly identifies which addon it belongs to, like MyAddon_CollapseContainer.

Noted.

You should add a check to prevent the function from creating frames for the same object more than once.

Will do this.

Finally, your code will be a lot easier to read and maintain if you use consistent indentation, spacing between comma-separated items, line breaks, and consistent naming practices (variables are lowercase, function and object names are camelcase, etc.).

While not an expert. I've been coding in PERL, Clean, lsl, various scripting environments and even RPN (now learning LUA). My syntax formatting has always been however was easiest for me. I've never been lost in maintaining my own stuff. I usually do not share. So being correct when its just me, and I am never lost. What does it matter? The code runs the same. And never lose what something does. Thank you for caring though, its nice to have helpful people around.

---
I do appreciate the help, and thanks for that.

To get how it simply was intended. I know its not a complex script, but might give you an idea of what I wanted for it. If you load it into wow. And play with it. I didn't notice issues it had with other containers. Why I didn't consider frame levels. As I could call in my test 10 containers in various locations. So not sure what setting frame level solves in this? One thing I ran into that I will play with later. Is a container in a container stay together (mostly and only if the parent is moved). Then when the child is dragged it unhooks. Was thinking I'd like to provide a way for it to rehook on moving the child frame back over the parent. Though not sure with LUA, have not poked it enough. If a window can detect when another window is over it, and that it is being dragged by a user.

http://oi49.tinypic.com/96yntt.jpg -- picture of 6 containers using my original code.
left : 3 expanded containers
right : 2 containers non-expanded, 1 mouseover (collapse but highlight of it)

[Sieben11]

Was able to put some of your examples in. A few comments are below:

State is reflective of frame/button. Setting btn.state to enable self for state. Seems the same as just calling state unless there was a reason for this? State was meant to just control both.

Alpha is not reflective of clicks over mouseover/mouseleave. Locked only when clicked.

Button used clamp for it to always remain on screen with the frame it controlled. In the end I want to control when button moves closer to frame. To pushing the button on the other side. So people could set the tooltip on left or right. And the button would dynamically swap to the other side. While I am looking and I see _:GetRight() & _:GetLeft(). I want the swap only to happen if the button shifts in it's static position toward the frame. Also if I want to do unclamping, clamping to the container. Seems will have to use screen position of the dragged frame + screen position of parent. For clamping. Just enabling drag unclamps. Did not see a function that did all 4. Though simple enough to make. left + top + right + bottom.

Useful to get parent then + 1. Thanks.

Getting created before create was useful. Mostly if I forgot I had a container already named.
Can also define a name different in NAME to define two containers as well.

ie MyAddon_ContainerA would turn to MyAddon_ContainerA_Frame / MyAddon_ContainerA_Button
ie Then using MyAddon_ContainerB for MyAddon_ContainerB_Frame / MyAddon_ContainerB_Button

collapse_container("MyAddon_ContainerA",UIParent,true,100,100,28,28,"CENTER","CENTER") collapse_container("MyAddon_ContainerB",UIParent,false,100,100,28,28,"CENTER","CENTER")

[Phanx]

For future reference, please do not quote an entire 100-line post, especially when it immediately preceds yours.

Originally Posted by Sieben11 The button is part of the tooltip. ... So DIALOG keeps the button topmost without stepping over TOOLTIP. Then will allow TOOLTIP to show over it.

Tooltips are the little info boxes that pop up when you move the mouse cursor over something; for example, when you mouse over a player in the game world, a tooltip appears in the bottom right corner of your screen showing that player's name, guild, level, class, and PvP state.

A frame, button, or other object that is always visible on the screen to be collapsed/expanded is not a tooltip.

Use frame levels, not stratas, to control the layering of related frames.

Originally Posted by Sieben11 My syntax formatting has always been however was easiest for me. ... What does it matter? The code runs the same.

It matters because good formatting makes your code infinitely easier for humans to read.

For example, you indented a few lines apparently at random. However, when the whole file is indented consistently, the structure of functions, blocks, and other scoping levels is immediately obvious even before you read anything.

Similarly, in some places you do:

if X then Y
else Z end

while other places you do:

if X then
    Y
else
    Z
end

Again, it's a consistency issue. If the code is formatted consistently throughout, it's just easier to read quickly and see how the part you are looking at fits into the overall structure.

Spacing just improves readability. Compare "alpha,beta,gamma,delta" vs. "alpha, beta, gamma, delta". There's a reason we use spaces between words and sentences in English (and most other languages). It's easier to read. Your source code is not a SMS message or a macro with a limit on the number of characters it can contain, so there's just no reason to squish everything together and lose readability.

If you're a programmer by trade, or even have previous programming experience, I'd be very surprised if you did not think that consistent variable naming conventions were important. If you write some code, don't look at it for 6 months, and then need to go back and fix something because a bug cropped up, it's just way easier if you have a convention, so you can figure out what you're looking at without having to read the whole file. For example, if you see "foobar" you could know right away that it's a variable, while "Foobar" is a function, and "FOOBAR" is a constant (a variable whose value is static and never changed).

Even if you don't consider bad/inconsistent formatting a problem for your personal workflow (though you really should) if you want other people to be able to read your code and understand it as quickly and easily as possible, you should format it properly. Lack of indentation, lack of consistency, unnecessary "squishing", random naming, and other formatting issues make a huge difference in the readability of your code by people who did not write it.

Your code wasn't that long, but had you posted 1000 lines of code formatted the same way, frankly I would not have bothered to read it or give you any feedback, because I'd have to spend an hour fixing the formatting to make it actually readable first, and that's just way more time and effort than I'm willing to spend providing free advice on a WoW addon forum.

Originally Posted by Sieben11 State is reflective of frame/button. Setting btn.state to enable self for state. Seems the same as just calling state unless there was a reason for this? State was meant to just control both.

Yes, you should just use self.state (where self is some object) instead of state, always. This makes the state accessible from outside the scope of the "create container" function.

Originally Posted by Sieben11 Button used clamp for it to always remain on screen with the frame it controlled.

Clamp the frame, attach the button to the frame, and use clamp insets on the frame. If you clamp both, but don't use clamp insets, then you can drag the frame to the edge of the screen and the button will end up overlapping it.

http://www.wowpedia.org/API_Frame_GetClampRectInsets

[Sieben11]

Originally Posted by Phanx see prev

Tooltip is to be something someone can mouseover to view. Click to lock it. Click to affect the tooltip. Then click let the tooltip resume the way it was before. Was an idea to make things selectable from the tooltip as much as possible without pushing everything to options. IE more commonly used items maybe. All ideas right now.

I do know you, and know you are good. Though very few writers write a finished novel right from the start. And some of those writers are not professional at it. I know how to program and script (To some extent, maybe not the greatest). I'm writing more rough, as it helps me learn. I'd hate to show you some of my code that reference lengthy bits of single and dual letter functions. Even I do not get lost in that. Have not for years.

If it bugs you so much why offer to :

providing free advice on a WoW addon forum.

bug me over it? (You shouldn't feel like holding Formatting 101 over the internet). Nor are you obligated to do so. You can simply exclude that from mention when and if you wish to help.

I was looking more into functionality. Not you need to write in "x" way not in "z". You should be happy enough that I do not type in internet speak. And actually make full words. And not debate over it. I feel this is where for you and I this subject should end. Otherwise it becomes meaningless ranting across the internet. And I feel you have more important things. As do I. And to me that is all done and over with. And will get no more mention.
Lets agree to disagree.

As for LUA I am still learning the full syntax.

Simple example of single letter scripting. Wrote for you as an example.

integer x;
            string r;
            string s;
            list cmds=
            [
            "display","bonus","sensor"
            ];
                for(x=0;x<3;x++){
                    r=llList2String(cmds,x);
                    s=(string)id+(string)x;
                    llMessageLinked(LINK_SET,(integer)s,r,"17");
                }
        }

As far as advice you have "provided" some. Which I did end up using as noted before. The rest was honestly discarded. Thank you for the advice in that.

Yes, you should just use self.state (where self is some object) instead of state, always. This makes the state accessible from outside the scope of the "create container" function.

Yes knew what self was for. Just was not considering that use. And poking myself to not thinking of why I had not anticipated that. Currently it will not have much use. Though later it could.

Clamp the frame, attach the button to the frame, and use clamp insets on the frame. If you clamp both, but don't use clamp insets, then you can drag the frame to the edge of the screen and the button will end up overlapping it.

Thank you also for the mention on clamping. Will look into that and update accordingly.