I see that the SingleChildScrollView allows scrolling via the MacBook trackpad with two-finger-panning.
However, I cannot find any gesture recogniser that is triggered by two-finger-panning.
How is two-finger-panning implemented for SingleChildScrollView?
I found the answer. Scrollable listens to PointerScrollEvent.
https://github.com/flutter/flutter/blob/b007a81ad498eb9b7cd687fda0aa9d8d2bb77dc3/packages/flutter/lib/src/widgets/scrollable.dart#L642
However, there is no reliable way to detect when scrolling actually ended and is not just idle (the user lifted the fingers).
Related
Is there reliable/official way to completely disable user interaction with the view? Similar SO questions only suggest intercepting mouse events, but I'm looking for a complete solution, which will disable all interactions in view and it's descendants, including:
mouse events
trackpad
keyboard focus/events
accelerator keys
voice input
mind control techniques
whatever other official way for user to spawn control events from the UI
The view (and it's descendants) should also immediately lose keyboard/mouse focus once interaction is disabled.
This should be similar to what transitionFromViewController:toViewController:options:completionHandler: does without NSViewControllerTransitionAllowUserInteraction flag, but I can't find a way to do that outside an animation.
Update:
The other way to describe what I'm looking for is: view must act totally like it's hidden, but still be drawn on screen.
I'm trying to get interactive gesture recognition (specifically, zooming and panning) working for my Delphi / C++Builder 10.2 Tokyo app.
What I've done so far:
Add a TGestureManager, GestureManager1 to my form.
Set the form's Touch.GestureManager to GestureManager1.
Leave everything under Touch.Gestures unchecked, because I want interactive gestures (zoom and pan), not "standard" gestures.
Make sure that Touch.InteractiveGestures.igZoom is checked.
Assign an OnGesture event handler.
The OnGesture event handler is triggered as expected, but the event's EventInfo.GestureID (which is supposed to give the type of gesture - pan, zoom, etc.) is always 0.
What am I doing wrong?
"Standard" gestures (the various lines and shapes under Touch.Gestures.Standard and "interactive" gestures (panning, zooming, rotating) are mutually exclusive.
To process "standard" or "custom" gestures", add a TGestureManager.
To receive "interactive" gestures, you need to remove the TGestureManager. This Embarcadero DocWiki article, which explains how gestures work in VCL and FireMonkey, specifically says:
In order to use Interactive Gestures such as zoom and rotate in a component, you do not need to associate the component with a Gesture Manager.
This Intel article has more details on Windows' various gesture interfaces. What Delphi calls "interactive" gestures correspond to Windows' WM_GESTURE message.
Alright here is my issue. I have a Pivot view. Inside that pivot view a scroll viewer containing many stack panels and grids. On some of the grids I have MouseButton Up Events. What is happening is if I flick the scroll it scrolls as expected but when I release my finger most of the time it fires off the event from mousebutton up. Because technically I let up. The problem is these grids completely fill the screen so finding an area without a mousebutton up to scroll is near impossible. What I want to happen is if the user flicked to scroll I would ideally like it to ignore the mousebutton up event. It does this successfully sometimes but pretty rarely and I have noticed I have to flick pretty fast for it to work as expected.
Any ideas on how to prevent this activity. I assume there is as Listboxes work perfect.
i think u should use windows phone toolkit GestureListener to recognize flick event
I ended up setting a bool for when the scrollviewer was scrolling and based on that allowing the mouseup action to run my code. Here is the the site I used to implement the bool based on scrolling status.
http://blogs.msdn.com/b/ptorr/archive/2010/07/23/how-to-detect-when-a-list-is-scrolling-or-not.aspx
I'm working on a app in which I used a listbox inside a pivot control just like the outlook app does. The problem is sometimes when I scroll the list, a swipe gesture is triggered and it goes to another pivot item. This is very annoying, and it seems doesn't happen to the outlook app. Am I doing something wrong? How do I fix it? Thanks a lot.
If you're just using the default controls in the default way then you're not doing anything wrong in your code.
You haven't said if you're getting this on the emualtor or on an actual device. I find I sometimes do this on the emulator if holding the mouse at a slight angle or on an actual device if holding that in a funny way (such as when lying down).
Whether you scroll the listbox or the pivot will depend on whether your finger (or mouse-if using the emulator on a non touch-screen PC) first moves vertically or horizontally after first touching the screen. In my experience the scenarios described above can lead to this not always working as expected but I've never seen an issue with this on a real device being held in one hand and scrolled using a thumb.
Unfortunately this is hard for me to test myself because I have yet to get a Magic Mouse of my own, but I've been told by my testers who do have a magic mouse that momentum scrolling isn't working in my app. I've not subclassed NSScrollView, but scrollview's document view is all custom. I have not overridden scrollWheel: anywhere, either, and yet momentum apparently just isn't working. I'm not even sure where to begin. I thought it'd just send scrollWheel events and things would take care of themselves. (Scrolling with a wheel or on the MBP trackpad works as expected.) Obviously I must somehow be doing something that's stopping it, but I don't even know where to begin. Thoughts?
I figured this out awhile ago and the problem was that on scroll, I was doing a lot of fancy view manipulation somewhat like how on the iPhone the UITableView adds and removes views as they scroll on and off screen. This worked great for performance - but the more I got into OSX programming, the more I realized this was wrong for OSX (but the right idea of iPhone).
Anyway, what's really going on, it seems, is that when you do something like a wheel scroll, the scroll event is sent to the view that's under the mouse cursor and then it ripples down the responders/views until it gets somewhere that handles it. Normally this isn't a problem, but with momentum scrolling the OS is really just sending ever smaller scrollWheel events to the view that was under the cursor at the time the momentum started. That means if the view is removed during the course of scrolling (because it scrolls off screen or something), it breaks the chain and the momentum stops because the view that's still getting the scrollWheel messages is no longer in the view hierarchy.
The "simple" fix is to not remove the view that got the last scrollWheel event - even if it's off screen. The better fix (and the one I went with) is to not try to use NSViews like they are UIViews and instead just draw the content using drawRect. :) Not only is that about a billion times faster, it Just Works(tm) with momentum scrolling because it's how OSX expects things to be done.
Repeat after me: OSX is not iPhoneOS.. :P
Odd scrolling behavior can occur when you don't set the Line Scroll and Page Scroll properties of the NSScrollView itself.
Beyond that, you're quite simply going to have to get a Magic Mouse - easily said or not :-) - to test this yourself or post the entire code of your custom view as well as the xib containing it. There's no way others can offer you more than guesses (like the above) without it.