BusyIndi​​catorをどのように実行しますか

BusyIndi​​catorに関する最近の投稿に応えて、この問題に関する彼の経験/ビジョンを共有することにしました。 私の意見では、この記事は雇用管理の指標のより単純な実装を示しています。 今では誰もが由緒ある開発会社の既製品を使用できますが、この場合の「漏れやすい抽象化」の問題は非常に緊急になります。 既成の指標を不自然な方法で使用すると、必然的に悲惨な結果につながります。 したがって、「どのように機能するか」を想像することは非常に重要です。

Otma3ka

• w Kodil、「 BusyIndi​​cator 」に関する近隣の投稿に触発されて
• 激しい熱意で、「ベストプラクティスガイド」を振り返ることなくコードを書きました。
• 実際、レッスンをどれだけよく学び、内部の「 10k Clock 」を更新したかは興味深い
• 上記と壊滅的な時間不足のため、コードは優雅に輝きません
• また、コードは普遍的ではありません。 既存のアプリケーションアーキテクチャに統合するのが難しい場合があります
• しかし、それはシンプルでわかりやすい（少なくとも私には）、そして最も重要なことは[反射]反射がないことです[/反射]

問題の声明

はい、しかし...与えられた：

• 何らかの形式のデータ入力が配置されるメインウィンドウ
  
• ウィンドウ内のフォームは、 パブリックプロパティBusyAdorner BusyAdornerを持つBaseAdornableControl：UserControl （または子孫）クラスのインスタンスです。
• このプロパティのセッターでは、ビジーインジケータが接続/切断されます
• メインウィンドウのDataContextには、デモViewModelのインスタンスの値が割り当てられます（「この変数Piを最愛の人で呼び出す」 SimpleBusyAdornerDemoViewModel ）
• ViewModelには1つのボビンプロパティIsBusyがあり、このプロパティの変更イベントの代わりにアクション[bool]があります
• 簡単にするためにイベントに煩わされませんでした（追加のハンドラークラスとその引数を宣言したくありませんでした）
• ロジックは次のとおりです。IsBusy値を変更すると、 アクション[bool] IsBusyChangedが引数として新しいIsBusy値で作動します
• Action [bool]へのサブスクライブIsBusyChangedは、 BaseAdornableControlインスタンスのBusyAdornerプロパティの値をnull （アドナーを切断）またはゼロ以外の値（アドナーを接続）に設定します。
• 繰り返しますが、簡単にするために、 IsBusy値をViewModelに反転するボタンをウィンドウに配置しましたが、たとえば、Webサービスに要求を送信して応答を受信するとき、ViewModelがそれを行う必要があることを知っています

メインウィンドウ

<Window x:Class="MyBusyAdorner.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:views="clr-namespace:MyBusyAdorner.Views" xmlns:adorners="clr-namespace:MyBusyAdorner.Adorners" Title="MainWindow" Height="350" Width="525"> <Grid> <Grid.RowDefinitions> <RowDefinition /> <RowDefinition Height="Auto"/> </Grid.RowDefinitions> <views:BaseAdornableControl x:Name="AdornableControl" BusyAdorner="{x:Null}" Margin="15"/> <Button Content="Attach/Detach" Grid.Row="1" Click="Button_Click"/> </Grid> </Window> 

 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Windows; using System.Windows.Controls; using System.Windows.Data; using System.Windows.Documents; using System.Windows.Input; using System.Windows.Media; using System.Windows.Media.Imaging; using System.Windows.Navigation; using System.Windows.Shapes; using MyBusyAdorner.ViewModels; using MyBusyAdorner.Adorners; namespace MyBusyAdorner { /// <summary> /// Interaction logic for MainWindow.xaml /// </summary> public partial class MainWindow : Window { private SimpleBusyAdornerDemoViewModel _viewModel; public MainWindow() { InitializeComponent(); DataContext = _viewModel = new SimpleBusyAdornerDemoViewModel(); _viewModel.IsBusyChanged = new Action<bool>((newValue) => { AttachDetachBusyAdorner(newValue); }); } private void AttachDetachBusyAdorner(bool isBusy) { AdornableControl.BusyAdorner = isBusy ? new BusyAdorner(AdornableControl) : null; } private void Button_Click(object sender, RoutedEventArgs e) { _viewModel.IsBusy = !_viewModel.IsBusy; } } } 

ここではすべてが簡単です。 ウィンドウには、マークするフォームがあります。 その下には、ViewModelのIsBusyプロパティの値を変更するボタンがあります。 すでに書いたように、このボタンはタスクの開始と終了を模倣します（非同期）。 この場合、非同期タスクとViewModelの相互作用のロジックがどのように実装されるかは重要ではありません。 TPLライブラリが使用されていると仮定します（ところで、これは私のmcDonnaldsです-「私はLovinだから...」）。 メインウィンドウのデザイナーで、 IsBusy変更サブスクリプションがアクションに作成されました。 この場合、ハンドラーは1つだけなので、Actionを使用できます。 それ以外の場合は、デリゲートを省略できませんでした。 そのため、ハンドラーはAdornableControlのBusyAdorner値を設定します：インジケーターを切断する場合はnull、アタッチする場合はnullではありません。

Busyadorner

 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Windows.Documents; using System.Windows; using System.Windows.Media; namespace MyBusyAdorner.Adorners { public class BusyAdorner : Adorner { public BusyAdorner(UIElement adornedElement) : base(adornedElement) { } protected override void OnRender(DrawingContext drawingContext) { var adornedControl = this.AdornedElement as FrameworkElement; if (adornedControl == null) return; Rect rect = new Rect(0,0, adornedControl.ActualWidth, adornedControl.ActualHeight); // Some arbitrary drawing implements. SolidColorBrush renderBrush = new SolidColorBrush(Colors.Green); renderBrush.Opacity = 0.2; Pen renderPen = new Pen(new SolidColorBrush(Colors.Navy), 1.5); double renderRadius = 5.0; double dist = 15; double cntrX = rect.Width / 2; double cntrY = rect.Height / 2; double left = cntrX - dist; double right = cntrX + dist; double top = cntrY - dist; double bottom = cntrY + dist; // Draw four circles near to center. drawingContext.PushTransform(new RotateTransform(45, cntrX, cntrY)); drawingContext.DrawEllipse(renderBrush, renderPen, new Point { X = left, Y = top}, renderRadius, renderRadius); drawingContext.DrawEllipse(renderBrush, renderPen, new Point { X = right, Y = top }, renderRadius, renderRadius); drawingContext.DrawEllipse(renderBrush, renderPen, new Point { X = right, Y = bottom }, renderRadius, renderRadius); drawingContext.DrawEllipse(renderBrush, renderPen, new Point { X = left, Y = bottom }, renderRadius, renderRadius); } } } 

これは一種の「ひねり」であり、雇用ViewModelを示す不気味な記念碑を生成することが理解されます。 この場合、画像は静的になりますが、回転ダイナミクスがRotateTransformの角度を更新するための十分なタイマーがありません。 ここでは、アニメーションの想像力を開放できます。 ちなみに、TPLの同じタスクを使用して、画像の回転角度をスムーズに変更できます（HMM ... ゲームループとしてのタスク？試してみてください！ ）。
したがって、次のようになります。

神は何を知っているのではありませんが、概念のデモンストレーションとして降りてきます。

BaseAdornableControl

 <!--    ... ..     --> 

 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Windows; using System.Windows.Controls; using System.Windows.Data; using System.Windows.Documents; using System.Windows.Input; using System.Windows.Media; using System.Windows.Media.Imaging; using System.Windows.Navigation; using System.Windows.Shapes; using MyBusyAdorner.Adorners; namespace MyBusyAdorner.Views { /// <summary> /// Interaction logic for BaseAdornableControl.xaml /// </summary> public partial class BaseAdornableControl : UserControl { #region [Fields] //private List<Adorner> _adorners = new List<Adorner>(); private BusyAdorner _busyAdorner; #endregion [/Fields] #region [Properties] public BusyAdorner BusyAdorner { get { return _busyAdorner; } set { DetachBusyAdorner(); _busyAdorner = value; if (value != null) { AttachBusyAdorner(); } } } private void AttachBusyAdorner() { if (_busyAdorner == null) return; var adornerLayer = AdornerLayer.GetAdornerLayer(this); adornerLayer.Add(_busyAdorner); } private void DetachBusyAdorner() { var adornerLayer = AdornerLayer.GetAdornerLayer(this); if (adornerLayer != null && _busyAdorner != null) { adornerLayer.Remove(_busyAdorner); } } #endregion [/Properties] public BaseAdornableControl() { InitializeComponent(); this.Unloaded += new RoutedEventHandler(BaseAdornableControl_Unloaded); } void BaseAdornableControl_Unloaded(object sender, RoutedEventArgs e) { DetachBusyAdorner(); } } } 

重要なお知らせ 。 装飾にラップされたコントロールをアンロードする前に、装飾を罪（メモリリーク）から切り離す必要があります。 AdornerLayerのロジックは非常に複雑であり、警戒心を失うと、レーキをかけることができます。 だから私はあなたに警告しました...

SimpleBusyAdornerDemoViewModel

 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.ComponentModel; namespace MyBusyAdorner.ViewModels { public class SimpleBusyAdornerDemoViewModel : INotifyPropertyChanged { #region [Fields] private bool _isBusy; #endregion [/Fields] #region [Properties] public bool IsBusy { get { return _isBusy; } set { if (value != _isBusy) { _isBusy = value; RaisePropertyChanged("IsBusy"); RaiseIsBusyChanged(); } } } public Action<bool> IsBusyChanged { get; set; } #endregion [/Properties] #region [Private Methods] private void RaiseIsBusyChanged() { if (IsBusyChanged != null) { IsBusyChanged(_isBusy); } } #endregion [/Private Methods] #region [INotifyPropertyChanged] public event PropertyChangedEventHandler PropertyChanged; private void RaisePropertyChanged(string propertyName) { if (PropertyChanged != null) { PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } } #endregion [/INotifyPropertyChanged] } } 

eventの代わりにActionを持つ「WTF-code」を除いて、MVVMパターンに精通している人にとって特別なことはありません。

追加機能-BusyAdornerManager

 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Collections.ObjectModel; using MyBusyAdorner.Adorners; using System.Windows; using System.Windows.Documents; namespace MyBusyAdorner.Services { public sealed class BusyAdornerManager { #region [Fieds] private List<BusyAdorner> _adorners; #endregion [/Fieds] #region [Public Methods] public void AddBusyAdorner(UIElement adornedElement) { if (adornedElement == null) return; var adorner = new BusyAdorner(adornedElement); _adorners.Add(adorner); } public void RemoveAllAdorners(UIElement adornedElement) { if (adornedElement == null) return; var adornerLayer = AdornerLayer.GetAdornerLayer(adornedElement); foreach (var adorner in adornerLayer.GetAdorners(adornerLayer)) { adornerLayer.Remove(adorner); } } #endregion [/Public Methods] #region Singleton private static volatile BusyAdornerManager instance; private static object syncRoot = new Object(); private BusyAdornerManager() { } public static BusyAdornerManager Instance { get { if (instance == null) { lock (syncRoot) { if (instance == null) instance = new BusyAdornerManager(); } } return instance; } } #endregion } } 

これは、任意のコントロールに装飾をぶら下げられるように設計されたサービスです。 また、kakulka-それはシングルトンではなく、単なる静的なクラスにすることができ、アドレナーのリストはまだ価値がありません。

おわりに

gitやその他のポイントが見当たらない場所に広めて、率直に言って、このような些細なことを台無しにしたくない。 私にとって、この投稿はスニペットであり、思考/知識を整理する試みであり、habreviewボードへのチケットです。 しかし、おそらく誰かが便利だと思うでしょう。 それで私たちは健康を批判します。「コードスタイルのガイド」についてはホリバーなしで...

UPD

継承のオーバーヘッドの問題について ...フォームのビューは一般にUserControlです。 UserControlの代わりにUserControlExまたは同じBaseAdornableControlなどのXAMLで記述することは本当に可能ですか？大きなオーバーヘッドですか？

純粋にMVVMアプローチを使用するという質問に ... DependencyPropertyをBaseAdornableControlに追加し、IsBusy ViewModelにバインドするのは簡単です。 このプロパティを変更するハンドラで、外部から注文したのと同じことを行います。 これは、サードパーティ製品の内部特性を反映した松葉杖を構築するよりもはるかに信頼性があります。 サードパーティの開発者が自分自身の内部を変えることをどう思うか誰が知っていますか？

アドナーをViewModelプロパティに直接バインドする問題について ...解説で書いたように、DependencyPropertyを含める必要があります。そのためには、たとえば、アドナーをFrameworkElementから継承する必要があります。 そして、これは非常に深刻なオーバーヘッドになります。特に、装飾者が常にメモリにハングアップする場合です。
Visifireコードをお楽しみください 。 または、少なくともSNOOP'omはBarChart'aツリーを歩きます。 そこで、チャートの各バーに対して、1つまたは2つの中間キャンバスが作成されます。 さらに、DataPointはFrameworkElementを継承し、DataPointを何かにバインドするか、 Colorプロパティを設定します（これはColorではなく、Brushではありません）。 そして冗談は、これらのDataPointsはFrameworkElementsであり、チャートのキャンバスに配置されるということです。 それらに、FrameworkElementsのもう1つのコレクションが新しく作成され、描画されます。 その結果、Visifireチャートはすでに600以上の要素でブレーキをかけ始めています。 比較のために：動的データ表示->折れ線グラフ-> 60k要素（特に滑らかなグラフィックス）->通常描画されます。
したがって、ViewModelに直接バインダーを決定すると、まったく不要なオーバーヘッドが発生します。

UPD2

ToolKitインディケーターの使用に関する質問に ...
コメントがあります...読んでください。 たとえば、次のコード：

 BackgroundWorker worker = new BackgroundWorker(); worker.DoWork += (o, ea) => { //long-running-process code System.Threading.Thread.Sleep(10000); DispatchService.Dispatch((Action)(() => { //update the UI code goes here // ... })); }; worker.RunWorkerCompleted += (o, ea) => { this.ResetIsBusy(); //here the BusyIndicator.IsBusy is set to FALSE }; this.SetIsBusy(); //here the BusyIndicator.IsBusy is set to TRUE worker.RunWorkerAsync(); 

そこで表示されるインジケータは、基本的に、非同期タスクの進行状況をユーザーに通知するために設計された特別なダイアログです。 このダイアログは、ウィンドウ/アプリケーション全体で実行されます。 ここに表示されるインジケータは、メモリ消費量が高くなることを恐れずに、コントロールごとに個別にハングアップできます。 異なるカテゴリー。