@LucasHainesこれは、これまで調べてきた入力検証機能とどのように関連していますか？

@jevansaksこれは、私が概説している入力検証作業に直接関係しています。

すごい。 共有するプレビューのものがある場合は、それを試して、フィードバックや考えを提供できることをうれしく思います。

これは、ビルド2018で言及された種類の検証です

`
x：Name = "UserName" Header = "ユーザー名："
Text = "{x：Bind ViewModel.Person.UserName、
UpdateSourceTrigger = PropertyChanged、
Mode = TwoWay} "/>

x：Name = "Password" Header = "Password："
Password = "{x：Bind ViewModel.Person.Password、
UpdateSourceTrigger = LostFocus、
Mode = TwoWay} "/>
`

@thomasclaudiushuber {Binding}の一部としてこれを機能させることはどれほど重要だと思いますか？ 私が尋ねるのは、技術的な課題が自明ではなく、ダウンレベルで機能できないためです。 私たちの当初のアイデアは、マークアップコンパイラの変更のみを必要とし、ダウンレベルで動作できるx：Bindをサポートすることでした。

また、INotifyDataErrorInfoおよびDataAnnotationsパラダイムのサポートのみを計画していました。 Binding.ValidationRulesに類似したものを追加するつもりはなかったため、ValidatesOnNotifyDataErrorsが十分に必要であるとは感じていませんでした。

正しく実行できるように、この機能の開発を続けているので、フィードバックをお待ちしています。

@stevenbrix

簡単な答え：はい、あなたが考えていることと計画していることは素晴らしいと思います。 x：Bindだけで問題なく、INotifyDataErrorInfoだけでも問題ありません。

長いです：

x：Bind？ 👍

すべてのWPF-LOBの場合、コンパイル時に既知の一種のViewModelが常に存在し、ダックタイピングは行われていなかったため、x：Bindは問題ありません。 WPFと同じ構文を取得するためにサポートできると思ったので、この号でも{Binding}を作成しました。 しかし、これは非常に重要というよりも「持っているといい」です。 また、{Binding}とx：Bindは舞台裏ではまったく異なるものであり、{Binding}を使用したランタイムのものは、あなたが述べたように重要であるため、{Binding}については忘れてください。 x：Bindだけでそれを使用することはまったく問題ないと思います。これは、私が考えることができるユースケースで機能します。 そして、UWPとx：Bindで行ったすべての会議の講演から、x：BindはすべてのXAML開発者の最もお気に入りのUWP機能の1つであり、すべての開発者に「どこでもバインディングよりもx：Bindを優先する」と伝えました。できる"。 :) intellisense、perf、step-into-code、およびコンパイル時のエラーを取得すると、x：BindがUWPの新しいデフォルトになります。したがって、検証サポートがあれば、問題なく適切な決定を行うことができます。

INotifyDataErrorInfoとDataAnnotationsのパラダイムだけですか？ 👍

INotifyDataErrorInfoとDataAnnotationsパラダイムをサポートするだけで私には良いと思います。 WPFはデータ注釈を自動的に取得しません。Validatorクラスを使用して、INotifyDataErrorInfo実装に手動で接続する必要があります。 「DataAnnotationsパラダイム」と言うとき、これを意味しますよね？ または、開発者がプロ​​パティにデータアノテーションを配置するだけで、これが機能するようにする組み込みのDataAnnotationサポートを計画していますか？ ASP.NET Core MVCのように？ それは素晴らしいことですが、必要ではないと思います。 クラスValidationContext、Validator、ValidationResult、およびSystem.ComponentModel.DataAnnotationsの他のクラスを持つことで十分です。

Binding.ValidationRulesを追加しますか？ Noooooo ;-)

いいえ、絶対に追加しないでください。 INotifyDataErrorInfoで十分であり、最高です。 IDataErrorInfoサポートがWPFに追加された後、ValidationRulesを使用したことはないと思います（正しく覚えていれば、これは.NET Framework 3.5にありました）。 また、INotifyDataErrorInfoが.NET Framework 4.5に追加されたとき、顧客と私はすべてのプロジェクトでそのインターフェイスを入力検証に使用しました。 このインターフェースだけをサポートすることは問題ありません。

ValidatesOnNotifyDataErrorsを追加しますか？ いいえ、でも...

はい、これを追加する必要はありません。 しかし、それはBinding.ValidationRulesとは何の関係もありません。 このプロパティは、INotifyDataErrorInfoインターフェイスに直接関連しています。 WPFのBindingMarkup Extensionでは、ValidatesOnNotifyDataErrorsはデフォルトでtrueです。これは、バインドされたオブジェクトがそのインターフェイスを実装している場合、{Binding}が実装されたINotifyDataErrorInfo検証を取得することを意味します。 Bindingマークアップ拡張機能のValidatesOnNotifyDataErrorsプロパティをfalseに設定すると、BindingMarkup拡張機能は検証のためにINotifyDataErrorInfo実装を取得しません。 したがって、これをx：Bindで実装するのはそれほど難しいことではないかもしれませんが、必要ないかもしれません。 だから、いや、それをしないでください。 これを省略してもかまいません。 しかし、過去にこれが必要だったシナリオについて説明しましょう。

WPFコントロールは、デフォルトでValidation.ErrorTemplateを介して定義された赤い境界線を表示します。 ここで、FirstNameプロパティを持つクラスを持つINotifyDataErrorInfo実装があると仮定します。 必須であるため、FirstNameプロパティがnullまたは空の場合はエラーを返します。 ここで、TextBoxをそのFirstNameプロパティにバインドしました。 ユーザーがその名を削除すると、赤い境界線が表示されます。 素晴らしい、まさにあなたが望むもの。 ただし、UIの別の場所に、FirstNameプロパティにバインドされている別のコントロールがある場合もあります。 たとえば、タブヘッダーのTextBlock。 検証エラーが発生すると、WPFはそのTextBlockにも赤い境界線を表示します。 しかし、これはあなたが望むものではないかもしれません。 ユーザーが名を変更できるTextBoxだけでエラーが発生しますが、TabヘッダーのTextBlockではエラーが発生しません。 TextBlockの赤い境界線を取り除くために、TextBlockのErrorTemplateを編集する必要はありません。代わりに、ValidatesOnNotifyDataErrorsプロパティをfalseに設定して、TextBlock-FirstName-BindingのINotifyDataErrorInfo検証をオフにします。 これは、私がこのプロパティに対してこれまでに経験した唯一のユースケースです。 :)

これがお役に立てば幸いです。

概要

はい、私は完全に同意します。INotifyDataErrorInfoをサポートするx：Bindで入力検証を行うのは良い計画です。

いいえ、それは素晴らしい計画です、私はすでにとても興奮しています！

@thomasclaudiushuber詳細なフォローアップに感謝します！ あなたが説明するコアシナリオは、私たちが真の価値ドライバーであると信じているものとラインナップしているので、それは聞いて良かったです。 この機能とAPIの全体的な設計は流動的であり、主にWPFが以前に行った作業が原因です。 ここで呼び出すべきいくつかの主要なことがありました：

1. 上で説明したように、WPFの検証システムには、付加価値がないと感じたり、より良いパターンに取って代わられたりする特定の側面があったため、それらをUWPに導入する予定はありませんでした。

2. WPFの検証システムの特定の機能/機能は、UWPには存在しないコアWPF機能を利用します。 ここで最も注目に値するのはアドナーレイヤーです。これにより、WPFの任意のUIElementで、コントロールだけでなく、検証ビジュアルを表示できます（テンプレートパーツを追加することにより）。

3. UWP Xamlには現在、アタッチされたイベントの概念がなく、Validationクラスをミラーリングすると、Validation.Errorイベントが追加されます。 それは取引のブレーカーではありません。複雑さを増すだけなので、新しい概念を追加することには一般的に警戒しているので、注意が必要です。 その上、作業にはコントロールのテンプレートへの変更が必要なため、特定のテンプレートの変更を提供するコントロールのセットのみがそのまま使用できます。 一般的に言って、機能しているように見えるが、一部のシナリオでは機能しないAPIを使用することは適切な方法ではないため、そのモデルから離れた方がよいと考えていました。 これは、コントロールが実装する共通のインターフェースや属性のようなものを持つことを意味します。

私たちは、新しくエキサイティングなオープンソースの世界でAPIと仕様のレビューを行う方法をまだ理解している最中です。 コミュニティからのフィードバックをお待ちしております。APIの提案をすぐに公開して、コミュニティが見て、誰もがワクワクするようなものを見つけられるように支援できることを願っています。

@stevenbrix検証機能のオープンソース仕様を開始するときに、検証がどのように見えるかを示す図とサンプルシナリオを提供して、UI側の方が会話を少し広げられるようにしますか。 、コーディングより:)

@mdtaukもちろんです。 共有した現在のUIはまだ正確です。 フィードバックがある場合は、このスレッドで自由に提供してください。

@LucasHainesUIは私には良さそうです。 しかし、エラーの表示方法をどのように調整できるのでしょうか。 私はこれに関して何も見つけていません、そしてあなたがその分野で共有する何かをすでに持っているかどうかはわかりません。 WPFから添付されたValidation.ErrorTemplateプロパティのようなものはありますか？

このための正式な仕様/提案がいつリリースされるかについてのタイムラインはありますか？
これをより早く製品に取り入れるために私は何ができますか？

上記の@mrlaceyに同意します...これを実際に使用できるようになったので、できる限りサポートさせていただきます。

私たちはオープンスペックに取り組んでおり、スペックリポジトリで利用可能であることをみんなに知らせます。

質問：IDataErrorInfoもサポートしないのはなぜですか？ .net標準でサポートされていますが、サポートされていないのはおかしいでしょうか。 コンパイル時にバインディングに使用するインターフェイスをチェックすることもできるので、これを使用していない人のパフォーマンスに影響を与えることはありませんか？

オープンスペックリポジトリで入力検証のオープンスペックレビューを開始しました。 https://github.com/Microsoft/microsoft-ui-xaml-specs/pull/26

こんにちは皆さん、これをどのように追跡していますか？ETAはありますか？

@knightmeisterここで作成されたオープンスペックがあります。 レビューに気軽に参加して、機能の形成にご協力ください。 これは、WinUI3.0の一部として出荷する予定です。 WinUI 3.0ロードマップの詳細については、問題＃717を確認してください。

みなさん、こんにちは。スペックの最新サンプルをご覧ください。 @stevenbrixはサンプルにいくつかの素晴らしい更新を行い、他のフィードバックに対処しました。

1つの質問：検証情報はコントロール階層に流れ込みますか？ たとえば、コンテナコントロール（TabViewやPivotなど）は、無効な状態の子コントロールがあることを知ることができますか？

複数のコンテナコントロールを含む複雑なビューを考えてみてください。たとえば、子コントロールが無効な状態にあるときにピボットヘッダーのスタイルを変更するなどして、ビューのどの部分に注意が必要かを強調します。

これは私にとって重大な問題です。
私のXAML検証システム全体はWPF検証ルールに基づいており、 BindingExpressionからフィールドとエンティティモデルを読み取り、DA検証属性に従って検証ルールを作成します（これを参照）。

たとえば、コンテナコントロール（TabViewやPivotなど）は、無効な状態の子コントロールがあることを知ることができますか？

@tbolonはい、これは実行できることですが、これらのコンテナーにサポートが組み込まれる可能性は低いです。 この機能が組み込まれたFormコントロールを作成することを検討しましたが、現時点ではおそらくバックログにあります。 WPFと同様に、 ValidationError （名前が間違っている可能性があります）イベントがあり、各コントロールが無効/有効になったときに起動します。 ただし、このイベントはルーティングされたイベントではないため、聴きたい各要素をサブスクライブする必要があります。

私のXAML検証システム全体は、WPF検証ルールに基づいています。

@weitzhandler現在、WinUIにValidationRuleのようなものを追加する予定はありません。 これを使用すると、 ValidationAttributesを使用して、モデルにINotifyDataErrorInfoを実装させることになりますか？ 使用シナリオをよりよく理解するために、モデルとXAMLがどのように見えるかを確認したいと思います。

INDEIでは、すべてのエンティティとサブエンティティを実装する必要があります。
ルールを使用すると、変更は必要ありません。すべて、検証属性のみを使用して自動的に機能します。

INDEIでは、すべてのエンティティとサブエンティティを実装する必要があります。

これについて詳しく教えていただけますか？

ルールを使用すると、変更は必要ありません。すべて、検証属性のみを使用して自動的に機能します。

ほとんどの場合、 ValidationAttributesとINotifyDataErrorInfoを使用すると、すべて自動的に機能します。 ここでは、仕様に含まれるいくつかのコードスニペットを示します。これは、（うまくいけば）同じページにいるためです。

FWIW、このValidationBaseクラスをツールキットでライブにすることを計画しているので、この定型コードを自分で作成する必要はありません。

public class ValidationBase : INotifyPropertyChanged, INotifyDataErrorInfo
{
   public event PropertyChangedEventHandler PropertyChanged;
   public event EventHandler<DataErrorsChangedEventArgs> ErrorsChanged;

   protected void SetValue<T>(ref T currentValue, T newValue, [CallerMemberName] string propertyName = "")
   {
       if (!EqualityComparer<T>.Default.Equals(currentValue, newValue))
       {
           currentValue = newValue;
           OnPropertyChanged(propertyName, newValue);
       }
   }

   readonly Dictionary<string, List<ValidationResult>> _errors = new Dictionary<string, List<ValidationResult>>();
   public bool HasErrors
   {
       get
       {
           return _errors.Any();
       }
   }
   public IEnumerable GetErrors(string propertyName)
   {
       return _errors[propertyName];
   }

   private void OnPropertyChanged(string propertyName, object value)
   {
       PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
       Validate(propertyName, value);
   }

   private void AddErrors(string propertyName, IEnumerable<ValidationResult> results)
   {
       if (!_errors.TryGetValue(propertyName, out List<ValidationResult> errors))
       {
           errors = new List<ValidationResult>();
           _errors.Add(propertyName, errors);
       }

       errors.AddRange(results);
       ErrorsChanged?.Invoke(this, new DataErrorsChangedEventArgs(propertyName));
   }

   private void ClearErrors(string propertyName)
   {
       if (_errors.TryGetValue(propertyName, out List<ValidationResult> errors))
       {
           errors.Clear();
           ErrorsChanged?.Invoke(this, new DataErrorsChangedEventArgs(propertyName));
       }
   }

   public void Validate(string memberName, object value)
   {
       ClearErrors(memberName);
       List<ValidationResult> results = new List<ValidationResult>();
       bool result = Validator.TryValidateProperty(
            value,
            new ValidationContext(this, null, null)
            {
                MemberName = memberName
            },
            results
            );

        if (!result)
        {
            AddErrors(memberName, results);
        }
    }
}

モデルはそのクラスから派生し、次のようになります。

public class Person : ValidationBase
{
    private string name;
    [MinLength(4)]
    [MaxLength(6)]
    public string Name
    {   
        get { return name; }
        set { SetValue(ref name, value); }
    }
}

このPersonクラスがPageのViewModelプロパティに設定されていると仮定すると、それにバインドすると、検証が自動的に行われます。

<TextBox Text="{x:Bind ViewModel.Name, Mode=TwoWay}" />

これはあなたが今日行っていることとは少し異なるかもしれないことを理解していますが、必要がなければ、同じことを行う2つの異なる方法をサポートしないようにしています。 これが理にかなっているのか、それともまだ足りないものがあると思われる場合はお知らせください。

あなたは正しいですが、それはあなたのエンティティが非POCOである必要があります。
私はそれを試してみる必要があります。 LoBアプリでEntityBaseクラスを使用しても、それほど悪くはないかもしれません。 私はPOCOを使用するのに慣れています。

UWPには* HAVE検証*がありません!!!!!!! プロジェクトを始めたばかりです。 数年前までWPFに戻ります。

@ rufw91わかってるよね？

あなたの時間の制約は何ですか？ これの最初の実装はWinUI3アルファ版であり、WinUIデスクトップのプレビューが//ビルドの時間枠で間もなく登場するはずです。 年末までにRTMを行う予定です

UWPには* HAVE検証*がありません!!!!!!! プロジェクトを始めたばかりです。 数年前までWPFに戻ります。

今後数年間もWPFを使用することにしました。 私はすべて（WPF、SL、WP、UWPなど）を実行しましたが、最終的には1つの技術だけが堅実に見えます。これがWPFです。 おそらく数年以内に、WinUIがどこにあるかを確認するのは興味深いかもしれませんが、私は新しいテクノロジーに切り替えて、暗闇の中で一人にされることにうんざりしています。 WPFは成熟しており、うまく機能します。 おそらく数年のうちに、OSとしてのWindowsはまったく関係がなくなるので、プラットフォームにこれ以上投資する前に、それを待ちましょう。

おそらく数年のうちに、OSとしてのWindowsはまったく関係がなくなるので、プラットフォームにこれ以上投資する前に、それを待ちましょう。

Windows 10のインストール数が10億を超えたことを考えると、それが真実になるとは信じられません。 しかし、私は間違いなくあなたの欲求不満を感じており、WPFにとどまっていることであなたを責めることはありません。 FWIW、私たちのチームが現在WPFの所有権を取得しているので、そこで私たちに見てもらいたいことがあれば教えてください。

INDEIでは、すべてのエンティティとサブエンティティを実装する必要があります。

これについて詳しく教えていただけますか？

私のコードを使用すると、すべてのPOCOエンティティは、これらのインターフェイスを実装せずに、基本クラスなしで維持できます。 INPCは、Fodyを使用して自動実装されます。 私がするほとんどのことは、より洗練された検証が必要なときにIValidatableObjectを実装することです。 また、サブタイプでも機能します。

FWIW、このValidationBaseクラスをツールキットでライブにすることを計画しているので、この定型コードを自分で作成する必要はありません。

それは良くないね。 エンティティにすでに基本クラスがある場合はどうなりますか？ それが私がINotifyDataErrorInfoの大ファンではない理由でもあります。 INPCプロパティは、特に大量のエンティティを含む大規模なデータアプリを扱う場合、すでに頭痛の種になっています。

UWPにまだ適切な検証がないことは非常に衝撃的です。 これはほとんどすべてのアプリの重要な基本機能であり、最優先する必要があります。

UWPにまだ適切な検証がないことは非常に衝撃的です。 これはほとんどすべてのアプリの重要な基本機能であり、最優先する必要があります。

うん、それが私たちがそれに取り組んでいる理由です:)

それは良くないね。 エンティティにすでに基本クラスがある場合はどうなりますか？

ここであなたの使い方を理解しようとしています。 基本クラスとは何ですか？このクラスから派生できますか？

うん、それが私たちがそれに取り組んでいる理由です:)

どうもありがとうございました。 これ、そしてあなたの仕事の残りの部分。
ラベルには何が必要ですか-winui-3は何を意味しますか？

ここであなたの使い方を理解しようとしています。 基本クラスとは何ですか？このクラスから派生できますか？

OData Connected Serviceを使用して、クライアントでエンティティを生成しています。
生成されるオブジェクトは次のパターンです。

c# public abstract partial class ContactBase : Microsoft.OData.Client.BaseEntityType, INotifyPropertyChanged

ラベルには何が必要ですか-winui-3は何を意味しますか？

@weitzhandler
これは、入力検証がWinUI 3（現在計画されている3.0）に付属することを意味します。 WinUI 2には、現在メンテナンスモードになっているOSXAMLコードを変更する必要があるため、おそらく実現しません。

UnoプラットフォームアプリでUWPを使用しています。 うまくいけば、WinUIはそのリリース時にカバーされるでしょう。
アップデートしてくれてありがとう！

ここであなたの使い方を理解しようとしています。 基本クラスとは何ですか？このクラスから派生できますか？

基本クラスを持つことは、多くの場合、サードパーティによって義務付けられています。たとえば、使用する永続性フレームワークです。 UWP / WinUIも、検証のためだけに基本クラスを要求することはできません。 有用であるためにはインターフェースである必要があり、どのアプリケーションも基本クラスを利用できません。 （これは、それを使用したい人のための基本クラスを持てないという意味ではありません。それはオプションである必要があり、検証を行う唯一の方法ではありません。）

基本クラスを持つことは、多くの場合、サードパーティによって義務付けられています。たとえば、使用する永続性フレームワークです。 UWP / WinUIも、検証のためだけに基本クラスを要求することはできません。 有用であるためにはインターフェースである必要があり、どのアプリケーションも基本クラスを利用できません。

少しバックアップしましょう。 私が行った最後のいくつかのコメントは少し混乱を引き起こしたと思います、それは私の悪いことです。

モデルに必要なのは、 System.ComponentModel.INotifyDataErrorInfo （またはC ++の場合Windows.UI.Xaml.Data.INotifyDataErrorInfo ）を実装することだけです。 コンパイラは、 {x:Bind}を使用するときに、ビューに接続するコードを適切に生成します。

上記で参照したValidationBaseクラスは、これを実装するコミュニティツールキットでINotifyPropertyChangedとともに出荷することを計画していたヘルパークラスです。 ユースケースで許可されていない場合は、それから派生する必要はありません。

@stevenbrixをご説明いただきありがとうございます。

検証属性とIValidatableObjectはどうですか？それらはUWPランタイムによって尊重されますか？

前述のMaxLength属性のような他の属性は、ASP.NETのようにTextBoxの最大長が自動的に設定されますか？
DataTypeAttribute 、 EditableAttributeと同じです。
また、フィールドヘッダーを生成するためのDisplayAttribute 。
私が覚えている限り、それらはすべてSilverlightでサポートされていました。

（これを参照してください）。

検証属性とIValidatableObjectについてはどうですか？それらはUWPランタイムによって尊重されますか？

そのため、現在、 Required属性をサポートする予定です。 一部のコントロールでは、これを使用すると、ヘッダーテキストの横に小さなアスタリスクが自動的に表示されます。 必要に応じて、今後さらにサポートを提供していきます。 詳細を確認したい場合は、別の問題を開いてください。期待を設定するために、追加の属性サポートによってWinUI3の初期リリースが行われる可能性はほとんどありません。

IValidatableObjectに関しては、それがどのように機能するかわかりません。 一般化として、私たちのエンジンはINotifyDataErrorInfo.ErrorsChangedイベントをリッスンするだけで動作します。 モデルの実際の検証はアプリ開発者次第であり、通常、ターゲットからソースに値を転送するときに行われます。

おそらく、提案したValidationBaseの代替メソッドとして、 Validator.TryValidateObjectを使用して検証プロセスを実行し、検証結果をエンティティに挿入して変更を通知する一連の拡張メソッドが必要です。 ？
このように、 INotifyDataErrorInfoを実装するだけで簡単に実現できます。 INotifyDataErrorInfoから継承するインターフェイスを使用して、エラーコレクションを保持するプロパティを追加することもできます。これにより、UWPランタイムまたはツールキットは、代わりに自動検証可能エンティティとして認識し、実装されている場合はプロパティを自動的に設定できます。

おそらく、提案したValidationBaseの代替メソッドとして、Validator.TryValidateObjectを使用して検証プロセスを実行し、検証結果をエンティティに挿入して変更を通知する一連の拡張メソッドが必要ですか？

これは素晴らしいアイデアです:)

🦙新しいソースジェネレータパラダイムがここでも役立つかどうか疑問に思っていますか？

はい@ michael-hawker、私はあなたの考えが好きです！

新しいソースジェネレータの可能性について最初に読んだとき、私はしばらく前に同じ考えを持っていました。

新しいソースジェネレータパラダイムを使用すると、INotifyDataErrorInfoとINotifyPropertyChangedのバックグラウンドで多くのものを構築/生成できると思います。

検証用のデータ注釈を含む、T4、INotifyPropertyChanged、およびINotifyDataErrorInfoでこれを正確に行うPluralsightのWPFコースがあります： https ：//www.pluralsight.com/courses/wpf-mvvm-advanced-model-treatment
このコースでは、カスタムの添付プロパティを使用して接続します。
このコースの目標は、すべての入力フィールドに変更された場合に表示されるMVVM WPFアプリを作成する方法と、元の値を示すことです。

ですから、間違いなく、物を生成し、おそらくライブラリ（おそらくWCTの一部として）で終わるのは素晴らしいことです。 そして、WinUIのためにそのコースをやり直したいと思います。 :)

@ rufw91わかってるよね？

あなたの時間の制約は何ですか？ これの最初の実装はWinUI3アルファ版であり、WinUIデスクトップのプレビューが//ビルドの時間枠で間もなく登場するはずです。 年末までにRTMを行う予定です

@stevenbrixそうだといいのですが、WPFに戻らなければなりませんでしたが、実際にはもうすぐ完了しました。

これを開けました。

これをフォローアップするために、Twitterで@stevenbrixと会話した後、彼がここで提供した基本のINotifyDataErrorInfo実装を、新しいMVVM Toolkitに含まれる新しいObservableValidatorクラスに統合しました（ Microsoft.Toolkit.Mvvmライブラリ）、これはINotifyPropertyChangedとINotifyPropertyChangingも実装します😄

この号では、関連するコードと、そのライブラリに関連するすべての要約を確認できます。
また、MVVM Toolkitの元の問題へのリンクと、新しい開発者向けのドキュメントも含まれています。

これについての最新情報を教えてください。 UWP 10.0 18362がINotifyDataErrorInfoをサポートしているかどうか知りたい。 次のドキュメントページによると、 https：//docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo？ view = netcore-3.1 INotifyDataErrorInfoはUWP10.0に「適用」されます。 ただし、UWP 10.0 18362がインストールされ、ターゲットに設定されている場合、テキストボックスにINotifyDataErrorInfo検証が表示されません。 テキストボックスは、XAMLで次のように記述されます。

<TextBox Text="{x:Bind ViewModel.Username, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />

ここでは、 ReactiveValidationObjectをINotifyDataErrorInfoの実装として使用します。

@worldbeaterこれはWinUI3の最新のプレビューでのみ利用可能です、あなたはそれを使用していますか？

ありがとう@stevenbrix！ WinUI3を試してみます。 INotifyDataErrorInfoとUWPが仲良くなっているのを聞いてうれしい、ついに✨

@worldbeater 、まだプレビュー中ですので、フィードバックをお寄せください。 💪

ちなみに、 @ worldbeaterは、ドキュメントではUWP 10.0で利用可能であると述べていますが、それがサポートされているわけではありません。 ドキュメントが十分に明確ではありません。