На самом деле предмет говорит все.
<CollectionViewSource x:Key="MyData"
Source="{Binding}" Filter="{ SomethingMagicInXaml? }" />
Не то, чтобы у меня не было кода. Это просто придирается ко мне.
На самом деле предмет говорит все.
<CollectionViewSource x:Key="MyData"
Source="{Binding}" Filter="{ SomethingMagicInXaml? }" />
Не то, чтобы у меня не было кода. Это просто придирается ко мне.
Вы можете сделать что угодно в XAML, если вы "достаточно стараетесь", до написания целых программ в нем.
Вы никогда не обойдете код (ну, если вы используете библиотеки, которые вам не нужно писать, но приложение все равно полагается на него), вот пример того, что вы можете сделать в этом конкретном случае:
<CollectionViewSource x:Key="Filtered" Source="{Binding DpData}"
xmlns:me="clr-namespace:Test.MarkupExtensions">
<CollectionViewSource.Filter>
<me:Filter>
<me:PropertyFilter PropertyName="Name" Value="Skeet" />
</me:Filter>
</CollectionViewSource.Filter>
</CollectionViewSource>
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Markup;
using System.Windows.Data;
using System.Collections.ObjectModel;
using System.Windows;
using System.Text.RegularExpressions;
namespace Test.MarkupExtensions
{
[ContentProperty("Filters")]
class FilterExtension : MarkupExtension
{
private readonly Collection<IFilter> _filters = new Collection<IFilter>();
public ICollection<IFilter> Filters { get { return _filters; } }
public override object ProvideValue(IServiceProvider serviceProvider)
{
return new FilterEventHandler((s, e) =>
{
foreach (var filter in Filters)
{
var res = filter.Filter(e.Item);
if (!res)
{
e.Accepted = false;
return;
}
}
e.Accepted = true;
});
}
}
public interface IFilter
{
bool Filter(object item);
}
// Sketchy Example Filter
public class PropertyFilter : DependencyObject, IFilter
{
public static readonly DependencyProperty PropertyNameProperty =
DependencyProperty.Register("PropertyName", typeof(string), typeof(PropertyFilter), new UIPropertyMetadata(null));
public string PropertyName
{
get { return (string)GetValue(PropertyNameProperty); }
set { SetValue(PropertyNameProperty, value); }
}
public static readonly DependencyProperty ValueProperty =
DependencyProperty.Register("Value", typeof(object), typeof(PropertyFilter), new UIPropertyMetadata(null));
public object Value
{
get { return (object)GetValue(ValueProperty); }
set { SetValue(ValueProperty, value); }
}
public static readonly DependencyProperty RegexPatternProperty =
DependencyProperty.Register("RegexPattern", typeof(string), typeof(PropertyFilter), new UIPropertyMetadata(null));
public string RegexPattern
{
get { return (string)GetValue(RegexPatternProperty); }
set { SetValue(RegexPatternProperty, value); }
}
public bool Filter(object item)
{
var type = item.GetType();
var itemValue = type.GetProperty(PropertyName).GetValue(item, null);
if (RegexPattern == null)
{
return (object.Equals(itemValue, Value));
}
else
{
if (itemValue is string == false)
{
throw new Exception("Cannot match non-string with regex.");
}
else
{
return Regex.Match((string)itemValue, RegexPattern).Success;
}
}
}
}
}
Расширения разметки являются вашим другом, если вы хотите что-то сделать в XAML.
(Возможно, вы захотите указать имя расширения, т.е. me:FilterExtension, поскольку проверка "на лету" в Visual Studio может жаловаться без причины, он все равно компилируется и запускается, но предупреждения могут быть раздражающими.
Также не ожидайте появления CollectionViewSource.Filter в IntelliSense, он не ожидает, что вы установите этот обработчик через XML-элементную нотацию)
На самом деле вам даже не нужен доступ к экземпляру CollectionViewSource, вы можете напрямую фильтровать исходную коллекцию в ViewModel:
ICollectionView view = CollectionViewSource.GetDefaultView(collection);
view.Filter = predicate;
(обратите внимание, что ICollectionView.Filter не является событием вроде CollectionViewSource.Filter, это свойство типа Predicate<object>)
WPF автоматически создает производный тип CollectionView --or, например ListCollectionView, BindingListCollectionView и т.д. (Это зависит от возможностей, обнаруженных в вашей исходной коллекции) --for any ItemsSource, если вы не предоставите его при привязке источника IEnumerable -derived непосредственно к свойству ItemsControl.ItemsSource.
Этот автоматически предоставленный экземпляр CollectionView создается и поддерживается системой на основе для коллекции (примечание: не для элемента управления или цели привязки для каждого пользовательского интерфейса). Другими словами, для каждого s̲o̲u̲r̲c̲e̲, к которому вы привязываете, будет ровно один глобально общий вид "Default", и этот уникальный экземпляр CollectionView может быть извлечен (или создан по требованию) в любое время, передав IEnumerable статический метод CollectionViewSource.GetDefaultView().
Иногда, даже если вы пытаетесь явно привязать свой собственный тип CollectionView -derived к ItemsSource, механизм привязки данных WPF может обернуть его (используя внутренний тип CollectionViewProxy).
В любом случае, каждый ItemsControl со свойством ItemsSource с привязкой к данным всегда будет иметь возможность сортировки и фильтрации, благодаря некоторому преобладающему CollectionView. Вы можете легко выполнить фильтрацию/сортировку для любого заданного IEnumerable путем захвата и манипулирования его "По умолчанию" CollectionView, но обратите внимание, что все связанные с данными цели в пользовательском интерфейсе, которые в конечном итоге используют это представление - либо потому, что вы явно привязали на CollectionViewSource.GetDefaultView(), или потому что вы вообще не предоставили никакого представления - все будут иметь те же самые эффекты сортировки/фильтрации.
Что не часто упоминается по этому вопросу, помимо привязки исходной коллекции к свойству
ItemsSourceобъектаItemsControl(в качестве цели привязки), вы также можете "одновременно" получить доступ к эффективный сбор примененных результатов фильтрации/сортировки --exposed какCollectionView-derived экземпляраSystem.Windows.Controls.ItemCollection--by привязки из элемента управленияItemsсвойство (в качестве источника привязки).
Это позволяет использовать многочисленные упрощенные сценарии XAML:
Если для вашего приложения достаточно наличия единой, общей для всех возможности фильтрации/сортировки для данного источника IEnumerable, просто подключитесь непосредственно к ItemsSource. Тем не менее, только в XAML вы можете фильтровать/сортировать элементы, обрабатывая свойство Items в том же элементе управления, что и источник привязки ItemCollection. Он имеет много полезных привязываемых свойств для управления фильтром/сортировкой. Как уже отмечалось, фильтрация/сортировка будут совместно использоваться всеми элементами пользовательского интерфейса, которые связаны таким же образом с одним источником IEnumerable. --or -
Создайте и примените один или несколько отдельных (non- "по умолчанию") CollectionView экземпляров самостоятельно. Это позволяет каждой связанной с данными цели иметь независимые настройки фильтра/сортировки. Это также можно сделать в XAML, и/или вы можете создать свои собственные классы (List)CollectionView -derived. Этот тип подхода хорошо освещен в другом месте, но я хотел бы отметить, что во многих случаях XAML можно упростить, используя ту же технику привязки данных к свойству ItemsControl.Items ( в качестве источника привязки) для доступа к эффективному CollectionView.
CollectionView в WPF ItemsControl, обрабатывая ее свойство Items как привязка только для чтения источник. Это будет System.Windows.Controls.ItemCollection, который предоставляет привязываемые/изменяемые свойства для управления активным фильтром и критериями сортировки.
IEnumerable непосредственно к ItemsSource, ItemCollection, к которому вы можете привязаться в ItemsControl.Items, будет быть оберткой в оригинальной коллекции CollectionViewSource.GetDefaultView(). Как обсуждалось выше, в случае использования XAML связывание с этой оболочкой пользовательского интерфейса не представляет никакой сложности (в отличие от ItemsControl.Items), в отличие от связывания с базовым представлением, которое он переносит (через CollectionViewSource.GetDefaultView) поскольку первый подход избавляет вас от (в XAML, неудобной) проблемы с явным упоминанием какого-либо CollectionView вообще.
Но, кроме того, поскольку ItemCollection оборачивает значение по умолчанию CollectionView, мне кажется, что даже в коде позади (где выбор менее очевиден), возможно, также более практично привязывать к представлению обнародован пользовательским интерфейсом, поскольку он лучше всего настроен на фактические возможности времени выполнения как источника данных, так и его целевого элемента управления пользовательским интерфейсом.