UIDragScrollView usage

[JSwigart]

I have a grid of objects within a scroll view, there is also a single large "background" item with a UIDragScrollView such that you can drag anywhere within the scroll view to scroll it, as one would expect. Once items are added to the grid, by default you cannot drag on the items themselves to still invoke the scroll view dragging. As I understand it, the fix for this is to add a UIDragScrollView to each of the items as well, and indeed this seems to work.

Assuming all that is proper usage, I've encountered an issue that appears to require a fix within NGUI itself.

Since my grid items now have UIDragScrollView, they forward OnPress events to the underlying scroll view. The issue is that if any of my custom logic, such as a click event on the object itself, removes or disables the item in the grid(as is the case with the inventory swapping I am debugging), when that grid item gets the OnPress(false) to notify of the release, the item is disabled, so that event is not forwarded to the scroll view. This leaves the scroll view in a mPressed = true state and scrolling is broken, because LateUpdate doesn't apply the mScroll, and zeroes it out in the else from

1. // Apply momentum
2.                 if (mShouldMove && !mPressed)

[JSwigart]

Sorry, I posted too soon.

So the question is. Am I using NGUI wrongly in some situation, or is this the unhandled edge case that it seems to be?

I'm tempted to remove the active checks in UIDragScrollView.OnPress so that the unpress will go through properly but I wanted to ask if there was a more proper fix for this someone would recommend.

[ArenMook]

You're disabling elements that are being dragged? That is indeed unusual behaviour. Disabling things on click I can understand, but in OnPress(true) would seem premature. A disabled script can't receive events. Remember, if you really need to hide something, you can just set its alpha to 0. It will have the same exact effect, but the script will still be enabled and interactable.

[JSwigart]

In a mouse up handler of our drag and drop system we are triggering a quick move of the icon, and part of that functionality destroys the icon, because where it is moved to has a different representation. None of that logic is drag related, just a click based quick move, but since the UIDragScrollView has already forwarded the OnPress(true) to the underlying scroll view to set the mPressed variable, the OnPress(false) half of that press event is ignored due to the UIDragScrollView being disabled.

Seems that the UIScrollView relies on the receipt of both sides of an OnPress event or scrolling breaks in this manner, and that isn't a reliable guarantee with the many different intermediate components that could be disabled and break the propagation of the false half of that.

I was tempted to do a Notify(currentTouch.pressed, "OnPress", false); before destroying the icon to clear any lingering mPressed related issues with the underlying ScrollView, but then the Press of UIScrollView doesn't seem protected against getting a false event when it isn't in it's true state, so for instance, sending OnPress(false) will invoke any onDragFinished callbacks whether or not it was in mPressed = true state before that, so I could be introducing different bugs.