I suspect that iOS tweens scrolling. It doesn't get scroll changes any more often than LiveCode, but it tweens the values rather than jumping to the newly reported value. That can give the illusion that it is getting more events, or handling them quicker.
iOS has a "scrollViewDidScroll" message which maps to the LiveCode message, but as far as I understand it, iOS does not use this to perform the actual moving of content (it is made available to notify the app of the scrolling that is taking place). Rather, the iOS implementation puts the content to be scrolled in sub-views that can be buffered and scrolled smoothly. LiveCode's implementation of the iOS scroller doesn't use these sub-views (everything is on one view), so can only work off the messages being triggered. My understanding is that iOS doesn't guarantee to trigger these messages at every point change, so that is why we don't get the smooth movement.
I coded a quick iOS external that allows you to call the setContentOffset iOS method of the iOS scroller that is created by LiveCode. This method allows you to animate the scrolling to a particular offset, but by using the native iOS commands. While it did trigger a series of scroll messages and the LiveCode group scrolled, the animation was not 100% smooth for the same reason as above.
Try this as a button script:
I did try a similar script but was stuck with either making the scroll too slow, or making it appear jerky. I am going to have another go at it though....
_______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
