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」問題

回答

相關問題