WPF - 跳跃/抖动滑块控件导致“BringIntoView”出现问题答案

【问题标题】：WPF - Jumpy/jittery slider control causing problems with "BringIntoView"WPF - 跳跃/抖动滑块控件导致“BringIntoView”出现问题
【发布时间】：2015-04-03 15:23:38
【问题描述】：

我有一个框架元素需要时刻关注。为此，每当它超出范围时，我都会使用BringIntoView()。但是，我注意到BringIntoView() 不能很好地处理速度。当 UI 被快速操作时（在我的例子中，它是一个包含选择器的时间线），BringIntoView() 似乎无法跟上。当时间线中的选择器快速移动到容器边界之外时，BringIntoView() 将（似乎）尝试通过将选择器移动到远离边界的地方来预测这种速度。

Instead of a smooth scrolling effect that takes place when the selector is moved slowly, instead what we get is a jittery scroll with the selector constantly going back and forth between being at the edge of the container and in the middle of it.就好像它无法处理速度并放弃尝试通过将框架元素尽可能远离容器边界来进行精确移动。

我不知道BringIntoView() 是如何工作的，但我想要一些类似的东西，可以预测与框架元素的定位相比需要滚动的距离。还有类似“BringIntoView()”的东西吗？

【问题讨论】：

你试过 ScrollIntoView 了吗？
@ChrisW。我使用的元素没有 ScrollIntoView，但是我可能通过更改调用 BringIntoView 的时间来解决我的问题。编辑：不，没关系。
我无法移动它，因为它的许多属性都依赖于 UI 中的信息。它的宽度、Canvas.Left 位置和高度都取决于 UI 中的内容。我只是想知道为什么 BringIntoView 表现不佳，我该如何改变它。

标签： c# wpf xaml scroll frameworkelement

【解决方案1】：

经过大量搜索，我找到了这个帖子：

https://social.msdn.microsoft.com/Forums/vstudio/en-US/2d0d202b-caf7-4d71-a61f-bcaa33565cdd/jumpy-slider-control-behavior?forum=wpf

消除滑块中抖动/跳跃行为的解决方案与“BringIntoView()”完全无关，而是与控件后面的双向值绑定的速度有关。将Delay=1 添加到绑定中可以消除控件中的任何抖动行为。它实质上为双向绑定增加了 1 毫秒的延迟，从而使 UI 有时间进行相应的更新。

有一个权衡；由于 1 毫秒的延迟，UI 不太流畅。但这是一个很小的牺牲，至少对我来说是这样。

【讨论】：