WPF - Jumpy/jittery滑块控件导致“BringIntoView”问题

我有一个框架元素，我需要随时查看。要做到这一点，只要出现界限，我就会使用BringIntoView()。但是，我注意到BringIntoView()不能很好地处理速度。当用户界面以快速方式操作时（在我的情况下，它是一个包含选择器的时间轴），BringIntoView()似乎无法跟上。当时间轴中的选择器快速移动到容器边界外时，BringIntoView()将（似乎）试图通过将选择器远离边界来预测这种快速性。WPF - Jumpy/jittery滑块控件导致“BringIntoView”问题

代替当选择器缓慢移动时发生的平滑滚动效果，取而代之的是，选择器不断地在容器边缘和其中间来回切换。这几乎就好像它不能处理速度，并且尽可能地将框架元素尽可能地远离集装箱边界而放弃尝试进行精确的移动。

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

来源

2015-04-03 AliEgseem

您是否尝试过ScrollIntoView？ – 2015-04-03 15:43:23

@ChrisW。我使用的元素没有ScrollIntoView，但是我可能通过更改BringIntoView被调用时解决了我的问题。编辑：不，不要介意。 – AliEgseem 2015-04-03 15:48:19

我无法移动它，因为它的很多属性都依赖于UI中的信息。它的宽度，Canvas.Left位置和高度都取决于用户界面中的东西。我只想知道为什么BringIntoView正在采取行动，我该如何改变它。 – AliEgseem 2015-04-03 18:13:36

经过大量搜索的我来到这个线程：

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毫秒，用户界面不够流畅。但这是一个小小的牺牲，至少对我而言。

来源

2015-04-03 21:10:37 AliEgseem

WPF - Jumpy/jittery滑块控件导致“BringIntoView”问题

回答

相关问题