Hello. I’m working on setting up our UI, which is composed mostly of GUI.windows.
I would like to have the UI windows render in certain UI layers: a main layer at the lowest layer, a notification layer for dialogs and modal type windows in a layer above, and a debug layer that can show a debug window atop everything no matter what. I handle this now by having a set of draw scripts in each layer that draw various UI windows in each layer from lowest layer to highest layer.
Where I’m running into trouble is that it appears I’m given the option of BringWindowToFront or BringWindowToBack. This, as it logically should, brings a window all the way to front/back, and so I’m trying to find a way to bring a window depth up/down, but within the constraints of the layers I’ve set up.
Also, I’ve noticed that as I make the calls to draw the Windows (ala GUI.Window()), it is not guaranteed (and documentation confirms this) that the window procedures are called in the order of their draw: in fact, logging out debug information confirms that the order is not guaranteed. So I can’t just draw windows back to front in my designated order and call BringWindowToFront() on each draw() call.
So, is there any way to manipulate the window.depth? GUI.depth doesn’t seem to be involved with Windows, and I’d love to be able to set a depth of a window. What I ultimately want is the equivalent of a BringWindowToDepth() call, so that for example I could bring a CreateUser window up to the front of the main layer, but still under the Debug window in the debug layer.
I’ve used this approach before in past projects with good success, but in those cases I had the ability to control the order of draw.
After much searching and trying things, I ended up going almost completely away from Windows.
Instead, I used Groups. All my windows were converted to use Groups, which act as containers like windows, but with predictable drawing order (and clipping). Windows natively blocked input, and groups do not, so I had to write a custom manager to handle blocking input to the world, as well as a custom manager to handle dragging, resizing, etc. With groups, though, I can have the control I need for draw depth that I was looking for in Windows when I posted this.
Now that it’s done, it’s pretty slick and very adaptable and organized. I ended up employing portions of the GUIX third party controls as well, which simplified matters.
I still have one window that draws over everything (only one), which has a tabbed dialog with various diagnostic screens (in-game logging, various admin commands, a UI viewer for examining the UI Tree, and a list of hotkeys on each screen of the game).
We are moving away from using GUI.Windows too, and the current version of GUIX uses our own window code for the Designer windows, for similar reasons. You can also use GUIClips instead of groups if you need a bit more/different control.
Basically, GUIClip is part of how windows, and groups work. GUIClip is a class that stores a stack of clipping rects for the GUI. It has some static methods (such as Push and Pop) for adding and removing a clipping rect.
Basic usage is:
Inside OnGUI(), call GUIClip.Push(clippingRect) passing the rect you wish to clip to.
Now you draw any element that should render inside and be clipped by this rect. Note that the clipping system resets the coord system of its contents, so the 0,0 position will now be based on the x,y position of the clipping rect. If your contents disappear, this is likely what’s happening.
Call GUIClip.Pop(). This must be done after push, otherwise Unity will throw an error.
A modification to this is calling the overload of Push(…) that takes a scroll offset vector (Vector2) as a second parameter. You can do scrolling by just moving your elements within the rect, but this can be nicer.
There are a couple other methods accessible, but that is the most common usage.
Note that because this class is not documented, it can change with any new release without much warning, so keep an eye on that.
).