0

Sliderの値を、ネットワーク デバイスの音量を表す整数プロパティにバインドしています。このネットワーク リクエストには少し時間がかかり (通常は 100 ミリ秒未満)、何らかの理由で Slider が途切れ途切れに感じられます。

明確にするために単純化しすぎたコードを次に示します。

    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、サムをドラッグしている間にセッターが起動します。ネットワーク遅延の問題により、要求が完了するまでにかかるミリ秒数の間、スライダーはロックされます。

スライダーを再び滑らかにするにはどうすればよいと考えられていますか?

4

1 に答える 1

1

ボリュームを実際に取得および設定するコンポーネントから UI (スライダー) を分離することを検討してください。スライダーの値が変更されると、ボリュームを新しい値に変更するリクエストをキューに入れる必要がありますが、そのまま続行します。デバイスから UI を最初に描画または更新するときにのみ、デバイスのボリュームからスライダーの位置を設定します。おそらく、ボリュームがユーザーがドラッグしたものに設定されていることを意味することで逃げることができます.

編集

（完全な開示：私は自分で多くのWPFを行ったことはありません）

そこで、私が言いたいことの実用的な例を調べた後、UpdateSourceTrigger について学びました。これは、バインドされた要素をトリガーして再バインドするためのさまざまな方法を提供します。タイマーと組み合わせたこの例を見つけました。UpdateSourceTriggerスライダーをドラッグすると短いタイムアウトが開始され、その後UpdateSourceTrigger、データバインディングを更新するように指示されるという考えです。トリックは、ユーザーがスライダーの値を変更し続けると、タイムアウトが中断されることです。つまり、ユーザーが最終的に必要な値に落ち着くまで、デバイスは実際にはスライダーの値で更新されないということです。これにより、探しているスライド中にスムーズで応答性の高い UI が得られるはずです。現在と同様に、デバイスからのスライダーのライブ更新を引き続き維持できます。物事が少し明確になることを願っています。

于 2012-05-07T03:52:57.797 に答える