Anyway to fix the editbox frame strata?

[galvin]

On live this appears above the action buttons.

http://prntscr.com/bg4fyn

[syncrow]

ChatFrame1EditBox:SetFrameStrata("DIALOG")

[Ketho]

Originally Posted by galvin On live this appears above the action buttons. http://prntscr.com/bg4fyn

But on Live it appears below the action buttons for me...

[galvin]

Originally Posted by syncrow ChatFrame1EditBox:SetFrameStrata("DIALOG")

Tried that didn't work, maybe prat is setting it back, but even went into prat and modified the framestrata there. Only guess is the action bar is set to the highest strata. I tried frame level that didn't work.

[sezz]

There's also no editbox (visible) anymore when you press enter while on the combat log tab.
Didn't check Blizzard's code yet, because I assume that it is not intended...

[galvin]

Looks like I may have to waste screen space and push the whole chat box up a bit. Really annoyed by this.

[Fizzlemizz]

Depends on what you are trying to do but Prat can dock the editbox to the top of the chatframe or you can set it free-floating/locked to place it anywhere.

[Gello]

It looks like while ChatFrame1EditBox reports a "DIALOG" frameStrata, it's rendering as if it was on the same frameStrata as ChatFrame1 (its parent), or "BACKGROUND". MainMenuBar is "MEDIUM".

/run ChatFrame1:SetFrameStrata("DIALOG")

seems to move the editbox (and chat window) above the bars.

This looks like a bug, but maybe needs more testing to see if it's consistent behavior beyond these frames.

[p3lim]

As far as I remember, that was an issue even back in vanilla, I had a really bad monitor and was forced to play with a low resolution (this was before scaling options, and before I knew about addons).

[semlar]

There's a new frame widget method called SetFlattensRenderLayers, and essentially what it does is treat all of the children of a frame as if they were being drawn on the same level, as a part of it, rather than on separate layers that can overlap other frames.

From your descriptions it sounds like this is enabled for the chat frame, which means you'd either have to move the entire parent to a higher layer, reparent the edit box, or just disable that setting.

I don't seem to be able to log into the beta right now so I can't check.

[sezz]

Originally Posted by semlar There's a new frame widget method called SetFlattensRenderLayers, and essentially what it does is treat all of the children of a frame as if they were being drawn on the same level, as a part of it, rather than on separate layers that can overlap other frames. From your descriptions it sounds like this is enabled for the chat frame, which means you'd either have to move the entire parent to a higher layer, reparent the edit box, or just disable that setting. I don't seem to be able to log into the beta right now so I can't check.

GetFlattensRenderLayers returns false for the editbox and all parent frames.

[semlar]

Originally Posted by sezz GetFlattensRenderLayers returns false for the editbox and all parent frames.

In that case, it sounds like it's bugged. There isn't much point in setting a frame's strata if it doesn't make it show up above another frame.

[dssd]

That checks if the frame was explicitly set to flatten. Setting a frame to top level also implicitly flattens it. Some frames seem to always flatten also, like scroll frames, world frame and minimap(?). There doesn't appear to be a a function to check that currently. You just have to visually inspect them.

[Gello]

It's a bug with toplevel, which ChatFrame1 has (and ChatFrame1EditBox, but the parent is the culprit with this bug).

<Ui>
  <Button name="StrataParent" toplevel="true" frameStrata="MEDIUM" movable="true" parent="UIParent">
    <Size x="100" y="100"/>
    <Anchors>
      <Anchor point="CENTER"/>
    </Anchors>
    <NormalTexture file="Interface\Icons\WoW_Token01"/>
    <Frames>
      <Button name="StrataChild" frameStrata="HIGH">
        <Size x="80" y="80"/>
        <Anchors>
          <Anchor point="CENTER" relativePoint="RIGHT"/>
        </Anchors>
        <NormalTexture file="Interface\Icons\PetJournalPortrait"/>
      </Button>
    </Frames>
    <Scripts>
      <OnMouseDown>
        self:StartMoving()
      </OnMouseDown>
      <OnMouseUp>
        self:StopMovingOrSizing()
      </OnMouseUp>
    </Scripts>
  </Button>
</Ui>

On live clients the child frame will stay above other toplevel "MEDIUM"-strata frames (like bags) when bags are brought to the front.

On beta client the child frame will drop below other toplevel "MEDIUM"-strata frames when bags are brought to the front, even after a SetFrameStrata to "HIGH" or "DIALOG".

[semlar]

Originally Posted by Gello It's a bug with toplevel, which ChatFrame1 has (and ChatFrame1EditBox, but the parent is the culprit with this bug).

So you should be able to call ChatFrame1:SetToplevel(false) as a temporary fix for this.

It sounds like if you need to raise an "active" frame to the top right now you'll have to handle it yourself.

[galvin]

Originally Posted by Gello It looks like while ChatFrame1EditBox reports a "DIALOG" frameStrata, it's rendering as if it was on the same frameStrata as ChatFrame1 (its parent), or "BACKGROUND". MainMenuBar is "MEDIUM". /run ChatFrame1:SetFrameStrata("DIALOG") seems to move the editbox (and chat window) above the bars. This looks like a bug, but maybe needs more testing to see if it's consistent behavior beyond these frames.

That worked, thanks

[sezz]

changing the editbox parent back to UIParent (like it is on live) seems to fix all my issues.