Overlapping box colliders

[newDev]

Hi! I have a Scrollview with a widget (let's call it Container) in it. This widget has a number of children with BoxColliders. The problem is that BoxCollider of the Container overlap children BoxColiders. So the ScrollView can be dragged, but it's children elements can't be clicked. The situation is opposite, if i set children elements Depth bigger then Containets one. Is there a way to prevent it?

There was an alike topic http://www.tasharen.com/forum/index.php?topic=4445.0 where you said that there would be added a functionality to determine a list of widgets hit underneath. Tell me please, if it was added and how can i use it to solve my problem?

Thanks!

[ArenMook]

Don't put the box collider on an empty game object. Put it on a widget.

ALT+SHIFT+W, ALT+SHIFT+C.

Adjust the depth to place it in front or behind other widgets.

[newDev]

I didn't mesion, children objects of ScrollView are already Widgets with BoxCollider. I need the Container to be draggable and its children to be clickable at the same time.
The problem is that Containers BoxColliders overlap childrens ones and don't let touch to pass true the hierarchy of objects.

[ArenMook]

I understand, and my reply is exactly that.

You make the container draggable by doing what I suggested.

I explain this in the 3.0.7 video tutorial.

[thehangedman]

Hi!

I've got exactly the same issue.

> Adjust the depth to place it in front or behind other widgets.

If container is in front, I can't click other widgets, if it's behind, I can't mouse-scroll or start dragging through other widgets - and at least mouse-scrolling is vital.

(To avoid any misunderstanding - the container is draggable, but only via space not occupied by inner widgets)

> I explain this in the 3.0.7 video tutorial.

Could you please point to the more or less exact timing in the video?

[ArenMook]

Scroll view setup should be like this:

Window (sprite + box collider, UIDragScrollView pointing to the Scroll View below it)
- Scroll view (anchored to the Window)
-- Grid (if desired, UICenterOnChild would go here)
--- Child 1 (box collider + UIDragScrollView)
--- Child 2 (box collider + UIDragScrollView)
--- Child 3 (box collider + UIDragScrollView)
- Sprite for the draggable corner (sprite anchored to the Window, box collider, UIDragResize referencing the Window)

I create a draggable window with a scroll view inside it at around 23:30 mark: http://www.youtube.com/watch?v=B66xhIvYF00#t=1410

[thehangedman]

So I need to add UIDragScrollView to both container (as I want to be able to scroll by dragging "empty" background or scrolling mouse wheel over it) and children colliders. However it's rather unfortunate to have UIDragScrollView on children cause it complicates constructing windows from prefabs (for various reasons I have to do it in runtime) and critically breaks modularity of prefabs (my item prefabs now need a script that is valuable in the specific context only, and even worse - has nothing to do with their own behaviour). This can be hacked around this way or another though.

However, I wonder if the following feature is possible in NGUI's future: add properties to the widget to allow it to ignore specific types of events in which case those events are passed to the collider attached to the widget with smaller depth. So in my case if container background has a collider and a widget of depth 1, and children have colliders and widgets of depth 2, I could set "OnScroll" events to be ignored by children colliders, and that would pass them to the widget behind (container) - and allow to scroll my scrollview with mouse wheel without need for UIDragScrollView on them. This is a bubbling event in terms of WPF, and I can see it especially useful for OnScroll and OnTooltip events. I know about UIEventTrigger and legacy UIForwardEvent, but they are no way better then UIDragScrollView - they require knowing the forward target and so work bad with prefabs. The bubbling doesn't need the target - the event is just passed to the widget below.

Of course this is not the most important feature ever, but would be really nice to have one day (or any other solution addressing this issue).

But for now thanks a lot for your help, my issue is solved (not in ideal way but still).

[ArenMook]

Events in NGUI go to colliders. Whichever collider is on top (read: highest depth value) is the one that gets the events. There is no selective events, and no event bubbling. This is why you need the drag scroll view script on children as well. Adding one extra script to your prefab won't complicate anything.

[thehangedman]

> Adding one extra script to your prefab won't complicate anything.

It does. My GUI is very complex. I have to build it in runtime (from xml) from many "controls". Each control is a prefab. Some layouts are known at runtime only (they come from server). Generally I have no idea which prefabs get into scrollview. I can't put the script on each prefab "just in case", apart other reasons cause it's not the behavior I always want. That's why it complicates things.

Broken modularity (it's broken here cause I have to delegate part of scrollview behaviour to children within) always complicates modular systems.

I don't expect any reaction on that - just explaining what exactly is complicated. Still NGUI does the good job even for my obscure usecase, and I can hack around harshnesses. Let's leave this issue alone.

[ArenMook]

When instantiating your prefab you can always do a check

1. if (NGUITools.FindInParents<UIScrollView>(parentObject) != null)
2.     prefabInstance.AddMissingComponent<UIDragScrollView>();