Messages

1

NGUI 3 Support / Re: Overlapping box colliders

« on: March 13, 2014, 02:25:20 AM »

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

2

NGUI 3 Support / Re: Overlapping box colliders

« on: March 12, 2014, 11:41:13 AM »

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

3

NGUI 3 Support / Re: Overlapping box colliders

« on: March 07, 2014, 06:28:13 PM »

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?

4

NGUI 3 Support / Resize UIScrollBar

« on: November 22, 2013, 12:34:08 PM »

Hello,

I used to resize a scrollbar (on container resize) by resizing the background sprite.

This method doesn't work since this change:
FIX: Redesigned the scroll bar. It now uses the foreground sprite's starting dimensions as its full size instead of the background.

How do I resize a scrollbar in runtime now?

The most convenient would be to retain the old behaviour - at least optionally, but I can't find any way to resize a scrollbar at all now.

Thanks!