魔术鼠标动量滚动不起作用
不幸的是，这对我来说很难测试自己，因为我还没有拥有自己的魔术鼠标，但我的测试人员告诉我，他们确实有魔术鼠标，动量滚动在我的应用程序中不起作用。我没有子类化 NSScrollView，但滚动视图的文档视图都是自定义的。我也没有在任何地方重写scrollWheel:，但动力显然不起作用。我什至不知道从哪里开始。我以为它只会发送scrollWheel 事件，事情就会自行解决。 （用滚轮或在 MBP 触控板上滚动可以按预期工作。）显然我必须以某种方式做一些阻止它的事情，但我什至不知道从哪里开始。想法？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不久前就发现了这一点，问题是在滚动时，我做了很多奇特的视图操作，有点像 iPhone 上 UITableView 在屏幕滚动和滚动时添加和删除视图的方式。这对于性能来说非常有效 - 但我越深入 OSX 编程，我就越意识到这对于 OSX 来说是错误的（但对于 iPhone 来说是正确的想法）。
不管怎样，真正发生的事情似乎是，当您执行滚轮滚动之类的操作时，滚动事件会发送到鼠标光标下方的视图，然后它会波及响应者/视图，直到到达处理它的地方。通常这不是问题，但随着动量滚动，操作系统实际上只是将更小的scrollWheel事件发送到动量开始时光标下方的视图。这意味着如果视图在滚动过程中被删除（因为它滚动到屏幕之外或其他原因），它会破坏链条并且动量停止，因为仍在获取scrollWheel消息的视图不再位于视图层次结构中。
“简单”的修复是不删除获得最后一个scrollWheel事件的视图 - 即使它不在屏幕上。更好的解决方案（也是我使用的解决方案）是不要尝试像使用 UIViews 一样使用 NSViews，而只是使用 drawRect 绘制内容。 :) 不仅速度快了大约十亿倍，而且它还可以与动量滚动一起工作，因为这就是 OSX 期望的工作方式。
跟我重复一遍：OSX 不是 iPhoneOS..:P
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
当您不设置 NSScrollView 本身的 Line Scroll 和 Page Scroll 属性时，可能会发生奇怪的滚动行为。
除此之外，您非常简单地必须获得一个 Magic Mouse - 说起来容易，也可能不:-) - 自己测试一下或发布您的自定义视图的整个代码以及包含它的 xib。如果没有它，其他人无法为您提供更多的猜测（如上面的）。
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.