我在尝试向某个应用程序添加捏拉缩放等功能时遇到问题，该应用程序在 ScrollView 内部具有图像控件，而 ScrollView 位于 FlipView 内部。 Image控件和ScrollView控件在FlipView的ItemTemplate中。
这个想法是，如果用户在图像上进行缩放，它将激活代码，该代码将在图像控件中创建和显示图像的放大版本。 (本例中的 Image 控件包含一个 PDF 页面，因此我们需要更大版本的 PDF 页面，而不仅仅是 PDF 页面的放大和模糊 View )。
如果我将 ManipulationDelta 事件处理程序附加到图像，它将捕获由双指缩放手势产生的 ManipulationDelta 事件，然后我可以使用它来创建 PDF 缩放效果。但是......现在它不会捕捉滚动(拖动？)手势。或者更确切地说，这些也被 ManipulationDelta 事件处理程序捕获。我宁愿避免在此时必须实现代码以编程方式处理滚动。我是否有任何选择以某种方式将 ManipulationDelta 事件冒泡(或“超过”？)到任何可以处理滚动的事件？我认为这已经发生了，事件会冒泡到 ScrollView，然后处理滚动。但它似乎不是那样发生的。
我在 ManipulationDelta 事件处理程序中将 e.Handled 设置为 false。并将 IMage 控件上的 ManipulationMode 设置为“全部”。我试过“缩放”，但这没有帮助。
谢谢!
最佳答案
WinRT 中的 ScrollViewer 针对性能进行了优化，并在后台使用 DirectManpulation。这就是为什么同时从 ScrollViewer 滚动并在其中进行手势操作很棘手。
Rob Caplan(MS 员工)的这篇博文提供了更多信息: http://blogs.msdn.com/b/wsdevsol/archive/2013/02/16/where-did-all-my-gestures-go.aspx
Unfortunately there is no good solution if the app needs both scrolling and gestures (for example, to detect CrossSlides against the scrolling). In this case the only option to get the Pointer messages everywhere is to disable Direct Manipulation everywhere, but that disables scrolling as well. To get that back the app will need to detect the scrolling gestures itself and then navigate the ScrollViewer to the new location with ScrollToHorizontalOffset or ScrollToVerticalOffset or by updating the SelectedIndex. This is tricky and will be noticeably slower than letting the ScrollViewer do its thing. It should be avoided if at all possible.
希望对你有帮助
关于windows-runtime - 为什么将 ManipulationDelta 事件处理程序添加到图像会阻止滚动？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12375602/