Issues with SetLayer

[Levva]

I'm trying to create a tooltip that pops up when mouse hovers over bar. Its now working fine apart from sometimes it decides to hide behind some bars, sometimes it is on top of them. I plan to have a look at exactly what the GetLayer() says for each bar and for the tooltip but ran out of time tonight.

I was wondering however if anyone can shed light on any specific mechanism that could be used to ensure tooltip is always at the front of the bar frames I create.

[Levva]

I've done more debugging and SetLayer is constant for ALL the bars I have. Yet when I am displaying my tooltip that definitely has a frame layer and text layer that are set as 4 & 5 whereas the bar (based on Zorba's ones) have frame, text, timer, solid frames with layers 0,1,2,3. Is this valid?

What I am seeing is that when I move mouse over one bar it is right then move mouse over another bar and it draws the tooltip, using the exact same layer settings, and the tooltip appears BEHIND the bar.

I am suspecting a bug. Can anyone confirm that I am understanding SetLayer correctly ie: that a higher layer number should show on top of a lower one?

I've got example code Zorba if you need it.

[Lorandii]

AFAIK, 0 is UIParent; setting a positive number makes a frame display "closer" to you, and negative numbers "further" away from you.

Just like normal integers, 2 > 1 > 0 > -1 > -2 etc. I have no idea what the upper or lower limits are, if any.

[Sunspotsy]

I've done more debugging and SetLayer is constant for ALL the bars I have. Yet when I am displaying my tooltip that definitely has a frame layer and text layer that are set as 4 & 5 whereas the bar (based on Zorba's ones) have frame, text, timer, solid frames with layers 0,1,2,3. Is this valid?

What I am seeing is that when I move mouse over one bar it is right then move mouse over another bar and it draws the tooltip, using the exact same layer settings, and the tooltip appears BEHIND the bar.

I am suspecting a bug. Can anyone confirm that I am understanding SetLayer correctly ie: that a higher layer number should show on top of a lower one?

I've got example code Zorba if you need it.

SetLayer is not working for me either. (I am attempting to use it in pretty much the same manner)

EDIT: I managed to fix it by changing the parent. Check if your frames have the same parent.

[ZorbaTHut]

The rendering cycle works like this in pseudocode:

function renderFrame(frame)
  draw(frame)

  sort(children, byLayer)
  for child in children do
    renderFrame(child)
  end
end

All children of a frame will be grouped up, all children of a frame will be rendered on top of the frame. SetLayer influences the render order only within a group of siblings.

[Sunspotsy]

The problem I was having was that a child of a child was rendered below the first parent. When I set both children with the same parent, I were able to layer them properly.

[Karuul]

The rendering cycle works like this in pseudocode:

function renderFrame(frame)
  draw(frame)

  sort(children, byLayer)
  for child in children do
    renderFrame(child)
  end
end

All children of a frame will be grouped up, all children of a frame will be rendered on top of the frame. SetLayer influences the render order only within a group of siblings.

What triggers the "renderFrame" function?

The issue I am having is I have multiple objects on a frame. I want to be able to change their layer on the fly. But just doing a SetLayer does not seem to be changing anything. If I do a reloadui the layer will appear properly but just changing the layer doesn't seem to do it. I have tried SetVisible(false) then true, I have tried changing the textures, I have tried making the parent frame hidden then visible but nothing besides a reloadui seems to work.

I'm assuming I'm just missing something simple here but for the life of me I can't figure out what it is.

[ZorbaTHut]

What triggers the "renderFrame" function?

The issue I am having is I have multiple objects on a frame. I want to be able to change their layer on the fly. But just doing a SetLayer does not seem to be changing anything. If I do a reloadui the layer will appear properly but just changing the layer doesn't seem to do it. I have tried SetVisible(false) then true, I have tried changing the textures, I have tried making the parent frame hidden then visible but nothing besides a reloadui seems to work.

I'm assuming I'm just missing something simple here but for the life of me I can't figure out what it is.

In this pseudocode, it happens once every frame. If it wasn't triggering, you wouldn't see anything

(The actual implementation is vastly different than this, it's just pseudocode.)

Can you reproduce the issue in a test addon?

[Naifu]

In this pseudocode, it happens once every frame. If it wasn't triggering, you wouldn't see anything

(The actual implementation is vastly different than this, it's just pseudocode.)

Can you reproduce the issue in a test addon?

I don't have a test addon available but I can tell you that there definitely are some issues. In the rather complex UI which nkAdvisor and it's widgets features I constantly run into layering issues. At some point it gets so complex, you have a hard time finding the item having a wrong parent or whatever the problem is.

The RunesOfMagic API was far from perfect but having a seperate XML file for the UI layout was much easier IMHO.

While I type in fact I maybe have an example in nkAdvisor. Just yesterday I had to shift around the order of creation of some items cause I couldn't get it properly layered whatever I tried. Will try to find that piece of code the tomorrow. Could well be in the end a fault in the programming but ... jesus ...

I personally would pefer a much simpler layering system where initially everything would be ordered in parent - child relationship and within the same relationship in order of creating within code. However on top of that it would be awsome to be able to assign say 10 layers indivdually for each context you create and then be able to overwrite standard layering by using SetLayer(x).

Your system works great as long as the UI is rather basic. But if you look at the "window > window.body > tabbed pane > tab body > combobox > tons of frames" relationsship in nkAdvisor (and that's even simplified view of things) I end up spending a huge amout of time just to draw all the different layers on a piece of paper to make sure overlapping works the way it should.

I don't event start with the yelling and shouting which could be heard in our house when I build the grid widget I'm using in my addons ...

Cheers
N.

[Levva]

My gut feeling is that layers should be based off UI.Parent. So that regardless of what frame you were on, calling SetLayer(x) on one frame produced IDENTICAL results to calling SetLayer(x) on another frame.

ie: if you used the same layer number then the system would guarantee they were on the same layer. More importantly if you used SetLayer(10) it would guarantee it was in front of ALL other frames that had SetLayer(1) through to SetLayer(9) regardless of who created the frame (ie: base UI or other addons).

The current system of everything off one parent being correct but things off a different parent being undefined leads to bizarre paradoxes and potentially a whole lot of grief drawing up layouts on paper as Naifu describes trying to avoid issues.

[Karuul]

I'm trying to get a simple test addon to reproduce the issue I am seeing but it seems that some level of complexity is needed to see the issue. So just poping overlapping frames on the screen and changing their layers seems to work fine. Therefore I'm leaning towards I must just be doing something wrong in my real addon. But I will keep poking at it and if I find something I will post it.

On the topic of SetLayer being absolute vs. relative I would disagree with absolute being the way to go. I'm currently running with multiple objects, each of which consists of a frame, texture, and text. I have my frame as the parent to the texture and text. So texture is layer 1 and text is layer 2 and this produces a nice picture with text on top of it. So working with relative layers I can set frame1 to layer 1 and frame2 to layer 2 and the images and text will follow suit and appear correctly. If we had absolute layers I would have to set the layer on frame1, texture1, text1, frame2, texture2 and text2 every time I wanted to update the layer.

[Karuul]

Ok, it appears that setting the layer of a frame from within another frame has issues.

Code for RiftAddon.toc 

Identifier = "kTest"
Name = "Karuul's Testing System"
Description = "Simple Test Addon"

Author = "Karuul"
Website = ""
Email = "Unknown@gmail.com"

Version = "0.01"
Environment = "1.5"

RunOnStartup = {
  "main.lua"
}

Code for main.lua

kTest = {}

kTest.context = UI.CreateContext("kTest")

function kTest.main()

	red = UI.CreateFrame("Frame", "Red", kTest.context)
	red:SetWidth(40)
	red:SetHeight(40)
	red:SetPoint ("CENTER", UIParent, "CENTER",0,-10)
	red:SetBackgroundColor(1, 0, 0)
	red:SetLayer(1)
	red:SetVisible(true)

	green = UI.CreateFrame("Frame", "Green", kTest.context)
	green:SetWidth(40)
	green:SetHeight(40)
	green:SetPoint ("CENTER", UIParent, "CENTER",0,10)
	green:SetBackgroundColor(0, 1, 0)
	green:SetLayer(2)
	green:SetVisible(true)
	
	button = UI.CreateFrame("RiftButton", "Button", kTest.context)
	button:SetText("Switch")
	button:SetWidth(100)
	button:SetHeight(40)
	button:SetPoint ("CENTER", UIParent, "CENTER",0,60)
	button:SetVisible(true)
	
	function button.Event:LeftPress()
		if red:GetLayer() == 1 then
			red:SetLayer(3)
		else
			red:SetLayer(1)
		end
		print("Set Red to layer " .. tostring(red:GetLayer()))
		print("Green is layer " .. tostring(green:GetLayer()))
	end
	
end

function kTest.commandHandler(commandline)

		red:SetLayer(red:GetLayer())
		
end

table.insert(Command.Slash.Register("kTest"), {kTest.commandHandler, "kTest", "config"})

kTest.main()

When you load the sample addon you will see a red box, a green box that overlaps the red box and a button below them. To start red is set to layer 1 and green is set to layer 2.

Clicking the button will change the layer of the red box and print out the layer of the red box and the green box. You will see that every time you click the button the Red layer changes but the screen does not update and the two boxes stay how they are.

If you then run the /ktest command you will see the boxes update. So if Red was 3 and Green was 2 the Red will be on top and likewise if Red was 1 and Green was 2 Green would be on top.

As you can see all the /ktest command does is red:SetLayer(red:GetLayer())

[ZorbaTHut]

Ok, it appears that setting the layer of a frame from within another frame has issues.

Huh. Yep, that's definitely a bug. Thanks, we'll get on it

Edit: Turns out the bug occurs when an input event fires after a frame order change but before the next frame. That means buttons that reorder frames will tend to not work. Horrible workaround: change the layer in the Event.System.Update.Begin event. We'll get a fix out ASAP.

[ZorbaTHut]

The current system of everything off one parent being correct but things off a different parent being undefined leads to bizarre paradoxes and potentially a whole lot of grief drawing up layouts on paper as Naifu describes trying to avoid issues.

It's not "undefined", it's just that children of different parents can never interleave. If you want that behavior, you just don't parent the frames that way.

We're currently fixing a bug in the ordering code, however.

[Gralli]

Sorry to necro this thread, but it seems like an issue I'm currently having.

I want to append a tooltip to the main tooltip. Everything works fine until the main tooltip appears over another open window. Then my tooltip is no longer on top.

um_Tooltip:Show(UI.Native.Tooltip, "HELLO WORLD", "BOTTOMCENTER", 0, 20)

I think the issue stems that I declare um_Tooltip with my context as the parent, but was hoping that I could use SetLayer to compensate for that. Unfortunately, it does not look that way.

So is there anyway to force a window/frame/element to the top?