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.).
Code:
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)