Picking through overlapping controls

Unity Engine
1

To prevent mouse clicks passing through windows/controls we built a rectangle stack manager for picking. It uses repaint events to add each controls screen area and associated ID and then is only valid for use during non-repaint events.

This seemed to more or less work but then we hit what appears to be controlID’s changing the next frame in certain circumstances. Which I can kind of understand but leaves us in a bit of a conundrum especially as we are not certain on what specific events other built in controls change state or set events to used on etc.

As far as I can understand we should not need the rectangle stack anyway as in the repaint events at the end of the GUI frame each control could set itself as the one the mouse is currently over, and then after all those repaint events the one who set it last would be the one it is actually over. Unfortunately that would then mean that the controlID gathered for the mouse-over could as mentioned most likely become invalid after those repaint events and thus we would have lost track of it by the time it comes to be signalled in the client code.

I am aware of the GUIToolTip hack but I am actually more interested in how the tooltips are implemented as this situation is a lot more complicated than I describe due to custom other types of controls etc.

2

In fact digging through how the tooltips work in unity they seem to do what I say about assigning a variable for mouse over during repaint events but that again doesn’t ensure consistent control ID’s between frames unless I completely take over the control ID generation scheme :frowning:

3

Continuing to speak to myself here…

Is it true that controlID’s should actually be consistent between the repaint events of the previous frame and the first round of layout events of the next? As the call graphs in those cases should be the same - as the GUI call graph should only change when the event is NOT a Repaint or NOT a Layout - ie only during mouse event etc?

In which case what I have been suggesting should work or I have a bug somewhere or a clash in controlID’s.

Also I seem to have noticed that after a control gets a mouse or other such modifying event and uses it - it and only it gets an extra layout event directly afterwards before repaint events - is this correct?

4

Furthering my fantastic conversation with myself my current foundations of understanding the Unity GUI are now:

  1. mouse over can only be determined during repaints

  2. control IDs may change during non-repaint/non-layout events

  3. controls can only be removed/added during non-repaint/non-layout events

  4. getlastrect only works during repaint events

  5. getrect only works during non-layout events

  6. controls who use a non-repaint/non-layout event will get an extra layout event directly afterwards

  7. the event order is layout, user input events + additional layout events for them if used, repaint

If this is correct why isn’t this in the documentation!?

5

Sorry please ignore these bits as they are the rubbish result of me confusing myself:

“Also I seem to have noticed that after a control gets a mouse or other such modifying event and uses it - it and only it gets an extra layout event directly afterwards before repaint events - is this correct?”

It should be there is an extra layout event after each mouse event etc

6

I also find the documentation could use some more details on the more advanced behaviours of the UI. It’s fine if you want ot make a simple HUD, but if you need more advanced UI behaviours it’s another story… I hope Unity can improve it and provide more details on the implementation details in the future :slight_smile: