Create a visualtree off of a control template in c

2020-07-10 09:45发布

This is a follow up question to a previous question, wich didn't really get me anywhere: deterministic and asynchronous field validation in WPF

Since WPF doesn't support INotifyDataErrorInfo it seems, that I need to implement something like that myself (please correct me if I am wrong here). I need this because I want the ViewModel to trigger when to display special ErrorTemplates for certain fields (e.g. after the click of a button or after the end of a long running async validation operation or when the internal state changes in a way that certain fields suddenly become invalid).

I am considering to write a custom markup extension or behavior for this. It listens to my version of INotifyDataErrorInfo implemented by the ViewModel and creates a VisualTree from a special wellknown ErrorTemplate defined in XAML once the ErrorsChanged event was raised.

Once I have defined that template in XAML, how do I find it from my behavior/expression, materialize an actual visual tree out of it and then display it (probably somehow on an adorner layer) at the right field entry on my form?

2条回答
姐就是有狂的资本
2楼-- · 2020-07-10 10:27

INotifyDataErrorInfo is now included in WPF 4.5 along with a lot of other features. See the following links

Here is the link to the Visual Studio 11 Developer Preview:
http://msdn.microsoft.com/en-us/vstudio/hh127353

查看更多
仙女界的扛把子
3楼-- · 2020-07-10 10:42

You don't need a markup extension. I recently found myself wishing for the same behavior, so I created a solution that works for my needs. Hopefully this helps you as well.

The IDataErrorInfo interface actually contains everything we need in order to do asynchronous signaling. What it lacks is an event system to trigger notifications automatically. There is a relationship between that interface and the INotifyPropertyChanged interface. The combination of the two actually allows you to signal a change, somewhat indirectly.

First the control:

<TextBox
    Grid.Column="1"
    Width="100"
    Text="{Binding UpdateSourceTrigger=LostFocus,
        Path=Id,
        ValidatesOnDataErrors=true}" />

Pretty straightforward. The value of UpdateSourceTrigger is not important, and NotifyOnValidationError is not required, but won't hurt anything if you add it.

Next, the view model, which is just a contrived example. The important part is in the IDataErrorInfo indexer.

public class WindowViewModel : INotifyPropertyChanged, IDataErrorInfo
{
    public event PropertyChangedEventHandler PropertyChanged;

    private int _id;
    public int Id
    {
        get{ return _id; }
        set
        {
            _id = value;
            this.PropertyChanged( this, new PropertyChangedEventArgs( "Id" ) );
        }
    }

    public string this[ string columnName ]
    {
        get
        {
            object result = AsynchValidationCoordinator.GetError( columnName );
            if ( result != null )
            {
                return result.ToString();
            }
            return null;
        }
    }

AsynchValidationCoordinator is a class that tracks properties and any associated error information. For illustrative purposes, the key being used is just the property name, but you could as easily create a compound key to differentiate potential property collisions in scenarios with multiple view models.

public static class AsynchValidationCoordinator
{
    private static readonly ConcurrentDictionary<string, object> ErrorList = 
        new ConcurrentDictionary<string, object>();

    public static void CancelError( string propertyName, object error )
    {
        object value;
        ErrorList.TryRemove( propertyName, out value );
    }

    public static object GetError( string propertyName )
    {
        object error = null;
        if ( ErrorList.ContainsKey( propertyName ) )
        {
            ErrorList.TryRemove( propertyName, out error );
        }
        return error;
    }

    public static void RegisterError( string propertyName, object error )
    {
        ErrorList[propertyName] = error;
    }
}

Tracking property names is necessary, but you could create an entirely different way of tracking them, including tracking the names within the view model. This was just an easy way for me to apply a structured form quickly to an existing project.

So tying this all together, I added the following ICommand property to the test view model and bound it to a Button. (RelayCommand is from Josh Smith's MSDN MVVM article.)

public ICommand ValidateCommand
{
    get
    {
        return new RelayCommand( Validate );
    }
}

private void Validate( object value )
{
    Thread thread = new Thread( RaiseChanged );
    thread.Start();
}

private void RaiseChanged()
{
    Thread.Sleep( 3000 );
    AsynchValidationCoordinator.RegisterError( "Id", "Error Message Goes Here" );
    this.PropertyChanged( this, new PropertyChangedEventArgs( "Id" ) );
}

The source of the call is irrelevant. The important point that ties all of this together is the fact that once PropertyChanged is called, the IDataErrorInfo indexer follows in its tracks. Returning the error information that was registered in AsynchValidationCoordinator triggers the Validation.ErrorTemplate of the control with the relevant error message.

查看更多
登录 后发表回答