2012-05-07 9 views
0

Sliderの値を、ネットワーク化されたデバイスのボリュームを表す整数プロパティにバインドします。このネットワーク要求は少し時間がかかります(通常< 100 ms)。何らかの理由でスライダが不安定になる原因になります。スライダの双方向値バインディングの遅延により、不安定な動作が発生する

は、ここに明確に私の単純化しすぎコードです:

Private _playbackVolume As Integer 
    Private _deviceForDemonstrationPurposes As New Device 

    Public Property PlaybackVolume As Integer 
     Get 
      Return _playbackVolume 
     End Get 
     Set(value As Integer) 
      _deviceForDemonstrationPurposes.Volume = value 
     End Set 
    End Property 

    Friend Sub UpdateVolume(volume As Integer) 
     ' this is called by the instance of Device whenever its volume changes. 
     _playbackVolume = volume 
     RaisePropertyChanged("PlaybackVolume") ' INotifyPropertyChanged implementation. 
    End Sub 

PlaybackVolumeプロパティにバインドすると、まだつまみをドラッグしながら、セッターが起動するようになります。ネットワークレイテンシの問題のため、スライダは要求が完了するのに要する時間が非常に長い間ロックされます。

スライダを滑らかにするための最良のアプローチとは何でしょうか?

答えて

1

実際にボリュームを取得して設定するコンポーネントからUI(スライダ)を切り離すことを検討してください。スライダの値が変わると、ボリュームを新しい値に変更する要求がキューに入れられますが、そのメリットは継続します。デバイスから最初にUIを描画または更新するときは、デバイスのボリュームからスライダの位置を設定するだけです。あなたはおそらく、ボリュームがユーザーがそれをドラッグしたものに設定されていることを暗示することで逃れることができます。

編集

(フル開示:私はWPF自分自身の多くを行っていませんでした)

をだから私が何を意味するかの実用的な例を検討していた後、私はあなたを提供UpdateSourceTrigger、について学びましたバインドされた要素をトリガーして再バインドする方法はいくつかあります。私はthis exampleを見つけました。それはUpdateSourceTriggerとタイマーを組み合わせています。スライダーをドラッグすると、わずかなタイムアウトが始まり、その後UpdateSourceTriggerにデータバインディングを更新するように指示されるという考えがあります。トリックは、ユーザーがスライダの値を変更し続けるとタイムアウトが中断されることです。したがって、実際の効果は、ユーザーが最終的に希望の値に収まるまで、スライダーの値でデバイスが実際には更新されないことです。これまでのように、デバイスからのスライダのライブアップデートを維持することはできます。私は物事を少しはっきりさせることを願っています。

+0

でも動作しますが、ユーザーは他の手段(物理的なリモコンやアプリの2番目のインスタンスなど)でボリュームを変更することもできます。これは、スライダに間違った値を表示させる原因になります。これは、常に避けたいものです。 –

+0

基本的には、バインディングモードをOneWayToSource(またはそれが呼び出されているもの)に設定し、セッターに何らかの非同期形式を実装することです。 –

+0

OK、デバイスのロードまたはリフレッシュ時にのみ設定することができます。デバイスコンポーネントがUIに通知してスライダの値を設定する部分を離れて、スライダをドラッグしている間に一時的に更新を無効にするロジックを追加することができます。 – HackedByChinese

関連する問題