WoWInterface - Anyway to fix the editbox frame strata?

WoWInterface (https://www.wowinterface.com/forums/index.php)

- Legion Beta archived threads (https://www.wowinterface.com/forums/forumdisplay.php?f=177)

- - Anyway to fix the editbox frame strata? (https://www.wowinterface.com/forums/showthread.php?t=53715)

galvin

06-14-16 12:07 AM

Anyway to fix the editbox frame strata?

On live this appears above the action buttons.

http://prntscr.com/bg4fyn

syncrow

06-14-16 09:38 AM

Lua Code:

ChatFrame1EditBox:SetFrameStrata("DIALOG")

Ketho

06-14-16 09:58 AM

Quote:

Originally Posted by galvin (Post 315715)

On live this appears above the action buttons.

http://prntscr.com/bg4fyn

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

galvin

06-14-16 11:38 AM

Quote:

Originally Posted by syncrow (Post 315718)

Lua Code:

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	06-14-16 12:52 PM

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

06-14-16 03:07 PM

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

Fizzlemizz

06-14-16 04:15 PM

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

06-15-16 02:22 AM

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".

Code:

/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

06-15-16 06:14 AM

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

06-15-16 10:12 AM

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	06-15-16 11:30 AM

Quote:

Originally Posted by semlar (Post 315733)

GetFlattensRenderLayers returns false for the editbox and all parent frames.

semlar

06-15-16 12:24 PM

Quote:

Originally Posted by sezz (Post 315734)

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	06-15-16 01:12 PM

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

06-15-16 03:14 PM

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

Code:

<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

06-15-16 03:51 PM

Quote:

Originally Posted by Gello (Post 315737)

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

06-15-16 04:17 PM

Quote:

Originally Posted by Gello (Post 315730)

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".

Code:

/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	06-16-16 01:46 AM

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

All times are GMT -6. The time now is 04:18 AM.