Feature request: More standard button press events

[beorn]

Hi good NGUI folks,

Maybe I'm missing something, but NGUI button press handling seems to make it very hard to support *standard* UI behavior:


1) I'd like to track and show a different state for the button depending on whether OnClick will be called if OnPress(false) happens.  I've seen these states referred to as "armed" and "disarmed" before - armed means if I release the mouse button/finger it'll trigger the action of the button.

I'll need events to fire three different animations/tweens:

• OnArm(true) - show the button as in armed state (e.g., let the button shrink a little and darken)
• OnArm(false) - show the button in normal/disarmed state (e.g., let the button ease back into normal size & color)
• OnClick() - show the button activation (e.g., let the button pop and return to normal size & color)

It seems the only way to do this is to try to mimic the logic of OnClick in my own script, and do it incompatibly (see point 2 below for example).  It seems this should be the normal behavior, so shouldn't NGUI support this out-of-the-box?  (Or, let me know how to do it if I missed something!)


2) In NGUI, if I press down over a button, drag the mouse pointer out of the button, back in again, and then release OnClick is not fired.  This isn't how most UIs that I know of work - they'll still trigger the action if you move the mouse pointer back into the button before you release.


See

• http://docs.oracle.com/javase/7/docs/api/javax/swing/ButtonModel.html
• example script attached

[ArenMook]

Regarding #2: once the drag event begins, click event is canceled. NGUI has been like that from the very beginning so changing it now is likely to result in quite a few people saying "bug!".

[beorn]

Re 2 - isn't the current behavior a bug if it's inconsistent with what the end user expects? I can only verify OSX and iOS at the moment, but looks like that's how Java wants it as well.

Re 1 - any chance for something like OnArm making its way into NGUI?

[ArenMook]

Your #1 depends on #2. But even if I was to change #2, I wouldn't add OnArm stuff as you can already do this inside OnDragOver by checking UICamera.currentTouch.dragStarted.

[beorn]

#1 doesn't depend on #2. As long as the behavior of arming events are consistent with how ontrigger works, it's at least consistent from a visual / usability point of view.

#2 is the behavior in most games too, eg Candy Crush Saga and Hayday.

All I want to do is create a UI with buttons that work similarly to those games, which also works similarly to (all?) operating/windowing systems.

[ArenMook]

You can do that by commenting out line 1425 in UICamera.cs:

1.                                         // If the touch should consider clicks, send out an OnClick notification
2.                                         //if (currentTouch.clickNotification != ClickNotification.None)

[ArenMook]

...or, a more elegant solution that doesn't involve modifying NGUI code... inside OnPress function attached to your button:

1. UICamera.currentTouch.clickNotification = ClickNotification.Always;

[beorn]

Re points 1 & 2:

• #2 Seems to work, thanks.  Though I would hope that it becomes the default.  I can see some edge cases where something (the button or its background) is actually being dragged - in this case the default may have to be to cancel trigger events on drag - the drag event overrides the click.  In the normal case, though, "drag" events like what I have in the code isn't drag at all - it's just a way to track the mouse pointer / finger's location while depressed.
• #1 I don't see how I can avoid using OnDrag as I need to trace when the object under the mouse pointer / finger is no longer gameObject?  Isn't OnDragOver passed to the parent object when objects are dragged over them (and that's not the situation I have)?

Ideally, NGUI would help track the armed state of buttons as:

• NGUI owns the responsibility of when to trigger OnClick, and is the best to track button armed states so that they are consistent with when OnClick will actually be called.  NGUI could transparently handle the special case where drag events are actually used and we have to cancel re-arming of buttons.
• As mentioned, most polished games, and (probably) all window/operating systems exhibit this behavior, so it should be something that's easy to do by default in NGUI.
• NGUI can probably do it more effectively than the way I do it.

I've attached an updated script integrating some of your recommendations.  Given this is such a "standard" (and I guess recommended from a usability point of view) behavior, I just it was as easy as overriding OnArm and OnClick and adding animations into them.

[ArenMook]

OnDragOver is sent when you drag something over an object. OnDragOut is sent when you drag away. OnDrag is sent to the object being dragged with the delta. It's all covered in the doc page for UICamera.

[beorn]

Yes, so in this case, I'm not dragging anything over anything, so OnDragOver/Out won't work, right?  If I could make it work, that would of course be better since it means a lot fewer events to handle.  (See code attached in last post.)

[ArenMook]

OnDragOver/Out events are sent to what you dragged over/out, so yes if you wanted this handled on the object being dragged then it won't work for you, but your script that does the check in OnDrag will.