Scroll and OnClick events

[Maxii]

I've just updated to 3.7.1 and am trying to change to using the new generic delegates now that genericEventHandler has been deprecated in favor of said delegates. This is proving challenging...

In the case of onScroll, I'm finding that the delegate is only raised when there is a gameObject underneath the cursor, aka mHover != null. Previously, with the genericEventHandler field assigned, the OnScroll event was passed to the genericEventHandler whether or not there was a gameObject underneath the cursor. If there wasn't, the genericEventHandler gameobject was assigned as the gameObject. Thus there was an event for every user scroll action.

A similar situation seems to be present with onClick, where the delegate is raised only when there is a gameObject underneath the cursor...

While I think the fallthroughEventHandler could be used to fill in for the delegate not being raised, wouldn't it be better to have the delegates raised for all user mouse actions with the gameObject set to null when not over a gameobject?

This way we could always rely on the event occurring and test for the presence or absence of the gameobject.

[ArenMook]

Hmm yeah true. Change UICamera.Start to this and it should work:

1.         void Start ()
2.         {
3.                 if (eventType != EventType.World_3D && cachedCamera.transparencySortMode != TransparencySortMode.Orthographic)
4.                         cachedCamera.transparencySortMode = TransparencySortMode.Orthographic;
5.  
6.                 if (Application.isPlaying)
7.                 {
8.                         if (fallThrough == null) fallThrough = gameObject;
9.                         cachedCamera.eventMask = 0;
10.                 }
11.                 if (handlesEvents) NGUIDebug.debugRaycast = debug;
12.         }

[Maxii]

Thanks for the reply, but I'm confused. 

How does assigning the unassigned fallthroughEventHandler field to the camera's gameobject result in all onScroll/onClick events raising a delegate whether or not they are over a gameobject?

What I'm trying to get back too is the genericEventHandler behavior where every user mouse action (scroll, click, etc) generates an event whether or not the cursor is over a gameobject.

[ArenMook]

Fallthrough being set means there is always some object that will be getting the events. There will never be a situation where there is no object. This means that all callbacks will always work as there is always some object to work with.

I had a look at the code and too much would need to change for the callbacks to trigger even if there is nothing underneath. Touches were meant to work with objects, not nothing at all.

[Maxii]

Thanks for the explanation. I've indeed confirmed that your stopgap Start() change does result in regaining visibility to all events via the delegates, just like the genericEventHandler approach I relied on. Of course, I know you are aware that other issues pop up:

- With multiple cameras, there are multiple camera gameObjects,
- If the camera gameObject is the 2DCamera, isOverUI returns true even if the cursor is not over the UI,
- Setting fallThrough to a default value in Start breaks the [now deprecated] genericEventHandler functionality that relies on fallThrough being null, etc

As you recommended, a couple of years ago, I adopted the Ngui event system and now use it exclusively. I based my UI on having visibility to all events where I analyze them and then route them to where they should go. GenericEventHandler (or Fallthrough with a nothing mask) provided this visibility. This is what you were recommending at the time.

I would like to track your change to delegates, but losing visibility to some events breaks my UI.
I would like to request that you provide some mechanism to use delegates without losing visibility to events that used to be visible.

[ArenMook]

I'd like to get rid of the generic event handler altogether. The delegate approach is a lot more flexible and lets you subscribe to only specific events (such as click) without affecting others (such as hover), for example. I had a strong use case for that in Windward recently.

Multiple cameras isn't an issue as only the first one will set the fallThrough. You can also set it yourself, which will prevent the default behaviour.

isOverUI can be fixed like so:

1.         static public bool isOverUI
2.         {
3.                 get
4.                 {
5.                         if (currentTouch != null) return currentTouch.isOverUI;
6.                         if (hoveredObject == null) return false;
7.                         if (hoveredObject == fallThrough) return false;
8.                         return NGUITools.FindInParents<UIRoot>(hoveredObject) != null;
9.                 }
10.         }

1.                 public bool isOverUI
2.                 {
3.                         get
4.                         {
5.                                 return current != null && current != fallThrough && NGUITools.FindInParents<UIRoot>(current) != null;
6.                         }
7.                 }

[Maxii]

Thanks for sticking with me.

I've solved my issue by directly assigning fallThrough to a known, non-UI gameObject (my main camera). This makes sure all events are raised. I then subscribe to the events I'm interested in and, after confirming !isOverUI, test to see if the provided gameObject is the fallThrough. This gives me what I'm looking for - eg. an unconsumed click, a scroll, etc.

[ArenMook]

Excellent. I'll have this code in the next update (and it's in the Pro repository now).