MouseWheel Scroll that feels native

For trackpad, copy the mousewheel event into the mousemove event flagging mousedown and mouseup and modify it slightly to add the difference between initial y and final y…I only implemented the mousewheel in the demo…no trackpad(forum name says mousewheel). For a canvas, it would scroll more smoothly as it would account for pixels instead of scrollposition (which is line based). On windows it scrolls quite smoothly as a listbox…as is. But mousewheel and trackpad are two totally different entities. The demo included was a translation of Javascript code used to implement iOS inertial scrolling, if used on a custom canvas based control (ie via SimDesignerCanvas which has inertial custom listbox demos available… And listboxes with side letter indexing) it scrolls amazingly smooth :slight_smile:

Javascript code (explains how it all works and you could adapt easily for web edition as well):

http://ariya.ofilabs.com/2013/08/javascript-kinetic-scrolling-part-1.html

One problem you’re going to run into is the fact that a magic trackpad generates inertial scrolling events. I did a lot of work to get it right in piDogScrollingCanvas. If you treat the trackpad events like mousewheel events, you’ll get unpleasant results. Run the demo under cocoa and under carbon to see the difference. Cocoa scrolling is natural feeling, while carbon is not (Carbon canvas is not an NSView and therefore cannot get Cocoa events). You can’t just add motion. You have to look at what the user’s hand is doing (ie is the user’s hand still on the pad, or did they scroll and release?), and change your response accordingly.

The only way you’re going to get true native trackpad scrolling is to use a true native cocoa control. I’m hoping that NSScrollViews will be used in the new framework (iOS would not be pretty without it) :wink:

Here is a good place to start…

iOS doesn’t have nsscrolling api, rather touch events (touch started/ended and x, y coordinates as in mouseup/mousedown) and is implemented in the same manor as mentioned above. I don’t do much mac development(everytime a new major os version is released the last is obsolete and can’t be used for anything without upgrading.), but iOS and obj-c I’m quite adept with. Hopefully it will definitely be a built-in feature in the Xojo iOS framework. I find that Windows, Linux, and iOS have more in common by how they operate (besides Windows not being a true “real time” OS) and their API structure than any of the three compared to MacOSX.

Inertial scrolling on ios:
http://aijazansari.com/2011/04/25/implementing-inertial-scrolling-in-ios/

This is a serious bit of misinformation. Unless you’re talking about something very specific this statement is demonstrably untrue.

Inertial scrolling on iOS is irrelevant to mousewheel scrolling on OS X in a way that feels native. You can get close, but it still won’t be native. The OP (which was me) included mouse and trackpad because of this, precisely.

In my case , since I’m looking for native scroll, I wouldn’t want a cross-platform solution since inertial scrolling is not part of Windows. My original post was to see if there was a way to get the native one or one that felt native. So far the closest I’ve seen anywhere is Jim’s from pidog, and I can see now how much work it was (I was unaware about the magic trackpad sending inertial mouse movements, which explains A LOT, including why your demo doesn’t work with trackpads).

Ok, the following code is unsupported and will likely break in a future version of Xojo. It changes the view hierarchy !

But in any case…

A canvas inside an NSScrollView!
Enjoy!

[quote=89526:@jim mckay]Ok, the following code is unsupported and will likely break in a future version of Xojo. It changes the view hierarchy !

But in any case…

A canvas inside an NSScrollView!
Enjoy![/quote]
That is the exact elastic feel though! Right on! :slight_smile:

I just want to add that I considered doing something like this in piDogScrollingCanvas (and had requests for it), but decided that altering the view hierarchy would be a very bad thing somewhere down the line. But the example does give you something to put next to another control to see if your control’s feel is close to native…

ok, I reuploaded the file to show how the mouse events are unreliable in this setup. The mouseMove events are correct, but mouseDown and mouseDrag are not translated relative to the canvas, but are relative to the scrollview…

Definitely should be a feature request made to Xojo as Joe R. stated in another post about changing the view hierarchy is unsupported and will break in subsequent releases (maybe its a feature request already under development?)… although I’ve been told to avoid undocumented/un-kosher framework code in some applications since 2011, or the code “would break in future releases… especially webedition”… And here it is almost 4 years later and “most” works still perfectly. I’m sure the best method would be to consult Xojo first, then possibly Christian, to create a plugin to ensure nothing “breaks.”

Well, the problem is that even a plugin will break if you’re messing with the view hierarchy. As I understand it, it would be ok to create an NSScrollView and handle the drawing and mouse events etc yourself, but when you try to put a Xojo rectControl inside an NSView, you’re asking for trouble, plugin or not.

I’ve added Mouse coord translation!

No… it has UIScrollView.

see https://developer.apple.com/library/ios/documentation/windowsviews/conceptual/UIScrollView_pg/Introduction/Introduction.html

and
https://developer.apple.com/Library/ios/documentation/UserExperience/Conceptual/UIKitUICatalog/UIScrollView.html#//apple_ref/doc/uid/TP40012857-UIScrollView

Jim, how did you carry that out in your DataView ?

Does this mean we are bound to not use NSScrollViews ? I could really need that but I am afraid of reworking
code constantly due to possibles breaks. So we need to stick to customs scrolling ?

NSScrollViews are unsupported in Xojo, doesn’t mean that you technically can’t use 'em, just means that when you run into problems (and you will run into problems), Xojo can’t help.

Please sign onto this feature request if you would like a proper NSScrollView <https://xojo.com/issue/16134>

[quote=173694:@Rob Egal]Jim, how did you carry that out in your DataView ?

[/quote]

DataView inherits all of it’s scrolling from piDogScrollingCanvas. The optional NSScrollers are done by adding an NSScrollView as a subview of the piDogScrollingCanvas (DataView). Then I am essentially adding an empty NSView as the documentView of the NSScrollView. I manage the size of the documentView to match the effective size of the scrollingArea of the piDogScrollingCanvas. Then I handle the NSViewBoundsDidChangeNotification notifications of the documentView to control the drawing positions of the piDogScrollingCanvas.

PinchToZoom is handled with magnifyWithEvent of the NSScrollView.

Part of the reason for doing it this way is so that if that functionality breaks in the future, you’ll be able to revert to the built-in scrolling behavior of piDogScrollingCanvas (using scrollwheel deltas).

One caveat of using the NSScrollView is that the coordinates are all CGFloat (single under 32bit), so the ceiling is fairly low. If the effective scrollingArea exceeds the maximum of a single, I have to scale the values…

When 64bit desktop comes around (and CGFloat becomes a double), I’ll need to rework some code, but I expect it to be a fairly simple thing (as I’ve planned ahead).

[quote=173724:@Sam Rowlands]NSScrollViews are unsupported in Xojo, doesn’t mean that you technically can’t use 'em, just means that when you run into problems (and you will run into problems), Xojo can’t help.

Please sign onto this feature request if you would like a proper NSScrollView <https://xojo.com/issue/16134>[/quote]

Signed. Hope this helps. :slight_smile:

[quote=173791:@jim mckay]DataView inherits all of it’s scrolling from piDogScrollingCanvas. The optional NSScrollers are done by adding an NSScrollView as a subview of the piDogScrollingCanvas (DataView). Then I am essentially adding an empty NSView as the documentView of the NSScrollView. I manage the size of the documentView to match the effective size of the scrollingArea of the piDogScrollingCanvas. Then I handle the NSViewBoundsDidChangeNotification notifications of the documentView to control the drawing positions of the piDogScrollingCanvas.

PinchToZoom is handled with magnifyWithEvent of the NSScrollView.

Part of the reason for doing it this way is so that if that functionality breaks in the future, you’ll be able to revert to the built-in scrolling behavior of piDogScrollingCanvas (using scrollwheel deltas).

One caveat of using the NSScrollView is that the coordinates are all CGFloat (single under 32bit), so the ceiling is fairly low. If the effective scrollingArea exceeds the maximum of a single, I have to scale the values…

When 64bit desktop comes around (and CGFloat becomes a double), I’ll need to rework some code, but I expect it to be a fairly simple thing (as I’ve planned ahead).[/quote]

Gosh. That sounds like a lot of work but that’s the answer. You’re expecting a break but you’re prepared and
can rework you code.

Jim, do you also know how to add isFlipped true to the view?

Awesome, let’s see if we can get Xojo to implement this one. It will save a lot of hacking (and I mean a lot of hacking to get it to work correctly). I’ve been hoping for years now that this will see the light of day as we use NSScrollViews in almost all our applications (I can’t share the code, sorry).

The biggest problem is more complex interfaces placed into a NSScrollView, there are multiple issues and this can also lead to crashing (Yosemite made it far easier to crash, not just in Xojo, but Objective-C also).

I suggest that if anyone is serious about implementing a NSScrollView, they should read the following documentation.
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/NSScrollViewGuide/Articles/Introduction.html#//apple_ref/doc/uid/TP40003221

It’s a bit lengthy, but will save some pain once you have an understanding of how a NSScrollView works and how to use it correctly.

Scroll views are definitely one of those things where we need to do them and they are on our to do list.
Apple threw all of us a monkey wrench when they, yet again, sprung an announcement on us requiring 64 bit for iOS which meant we had to shift focus.
Instead of doing a bunch of controls we had to focus on 64 bit.
Otherwise we’d have a pile of nifty new controls that no one could really use because their iOS apps were 32 bit only and could not get put in the App Store.
Not really useful.

Best laid plans of mice and men and all that :slight_smile: