+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 15 of 20

  Click here to go to the first Rift Team post in this thread.   Thread: Issues with SetLayer

  1. #1
    Plane Touched Levva's Avatar
    Join Date
    Jan 2011
    Location
    Aberdeen, Scotland
    Posts
    243

    Default Issues with SetLayer

    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.
    Last edited by Levva; 10-12-2011 at 05:20 PM.

  2. #2
    Plane Touched Levva's Avatar
    Join Date
    Jan 2011
    Location
    Aberdeen, Scotland
    Posts
    243

    Default

    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.

  3. #3
    Champion Lorandii's Avatar
    Join Date
    Jun 2011
    Posts
    516

    Default

    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.

  4. #4
    Telaran
    Join Date
    Nov 2010
    Posts
    59

    Default

    Quote Originally Posted by Levva View Post
    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.
    Last edited by Sunspotsy; 10-16-2011 at 05:07 AM.

  5.   Click here to go to the next Rift Team post in this thread.   #5
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    The rendering cycle works like this in pseudocode:

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

  6. #6
    Telaran
    Join Date
    Nov 2010
    Posts
    59

    Default

    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.

  7. #7
    Telaran
    Join Date
    Feb 2011
    Posts
    63

    Default

    Quote Originally Posted by ZorbaTHut View Post
    The rendering cycle works like this in pseudocode:

    Code:
    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.
    Last edited by Karuul; 11-14-2011 at 07:35 PM.

  8.   Click here to go to the next Rift Team post in this thread.   #8
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Karuul View Post
    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?

  9. #9
    Champion
    Join Date
    Jun 2011
    Posts
    561

    Default

    Quote Originally Posted by ZorbaTHut View Post
    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.
    Last edited by Naifu; 11-15-2011 at 03:07 AM.

  10. #10
    Plane Touched Levva's Avatar
    Join Date
    Jan 2011
    Location
    Aberdeen, Scotland
    Posts
    243

    Default

    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.
    Last edited by Levva; 11-15-2011 at 03:37 AM.

  11. #11
    Telaran
    Join Date
    Feb 2011
    Posts
    63

    Default

    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.
    Last edited by Karuul; 11-15-2011 at 06:25 AM.

  12. #12
    Telaran
    Join Date
    Feb 2011
    Posts
    63

    Default Found the bug

    Ok, it appears that setting the layer of a frame from within another frame has issues.
    Code:
    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())

  13.   Click here to go to the next Rift Team post in this thread.   #13
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Karuul View Post
    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.
    Last edited by ZorbaTHut; 11-15-2011 at 04:47 PM.

  14.   This is the last Rift Team post in this thread.   #14
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Levva View Post
    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.

  15. #15
    Telaran
    Join Date
    Dec 2012
    Posts
    77

    Default

    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.

    Code:
    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?
    Last edited by Gralli; 01-26-2013 at 07:29 PM.

+ Reply to Thread
Page 1 of 2 1 2 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts