Log In
Home
Support
Demos
Documentation
Blogs
Training
Webinars
[Expand]General Information
[Collapse]WinForms Controls
  Prerequisites
 [Expand]What's Installed
 [Expand]Build an Application
 [Expand]Controls and Libraries
 [Collapse]Common Features
  [Expand]Data Binding Common Concepts
  [Expand]Data Source Wizard
  [Expand]Expressions
  [Expand]Behaviors
  [Expand]Application Appearance
  [Collapse]Filtering UI Context
    Filtering Events
    Filtering Attributes
    Base and Parent Filtering ViewModels
    Filtering UI Context Designer
  [Expand]High DPI Support
  [Expand]Scaffolding Wizard
  [Expand]Formatting Values
   HTML Text Formatting
  [Expand]Menus
  [Expand]Tooltip Management
  [Expand]Saving and Restoring Layouts
   Clipboard - Copy and Paste Operations. Data Formatting
   Version Compatibility: Default Property Values
  Get More Help
 [Expand]API Reference
[Expand]ASP.NET Controls and MVC Extensions
[Expand]ASP.NET Bootstrap Controls
[Expand]ASP.NET Core Bootstrap Controls
[Expand]WPF Controls
[Expand]Xamarin Controls
[Expand]Windows 10 App Controls
[Expand]Document Server
[Expand]Reporting
[Expand]Report Server
[Expand]Dashboard
[Expand]eXpressApp Framework
[Expand]CodeRush
[Expand]CodeRush Classic
[Expand]Cross-Platform Core Libraries
[Expand]Tools and Utilities
 End-User Documentation

Base and Parent Filtering ViewModels

The Filtering UI Context works with a filtering ViewModel, which is generated automatically from a filtering Model you provide. The ViewModel contains all business logic required to identify valid properties, parse filtering attributes and generate the required editors.

You can modify this inaccessible ViewModel layer using the MVVM-based approach, by inheriting it from a custom class (base ViewModel) and\or relating it to another class (parent ViewModel) via the parent-child relationship.

To specify the base ViewModel, use the component's smart tag (in "Advanced Binding" mode) or set the BaseViewModelType property programmatically.

To set the parent ViewModel, either assign its instance to the ParentViewModel property or specify the MvvmContext component that manages the same ViewModel.

There is no specific recommendation on whether to use the base ViewModel only, the parent ViewModel, or both simultaneously. Use the approach that best fits your needs.

Expanded Replacing Filtering Events

As the diagram above shows, filtering events no longer take part in this MVVM-like approach since handling events breaks the main MVVM concept of separating a GUI from application logic. Instead, use filtering attributes whose parameters that end with '...Member'. The example below illustrates how to populate a look-up editor without handling the QueryLookupData event.

The CustomFilteringViewModel class uses the RetrieveCategoryList method to return a list containing all the existing category names. The public ProductCategories property returns this list with one additional custom item added to it.

You can use this class's ProductCategories property to set the DataSourceMember parameter if you are using it as a base or parent ViewModel. Setting this parameter is identical to passing a lookup item collection to the QueryLookupData event handler's e.Result.DataSource property. You can also specify the ValueMember and DisplayMember parameters to assign two additional base or parent ViewModel members. The first member is used to build filter criteria objects while the second member returns values that are displayed to an end-user. Use these parameters when you have paired data fields like 'ModelName' and 'ModelID'.

The same applies to the remaining filtering events:

  • Add the FilterRange attribute and specify its MinimumMember, MaximumMember, and AverageMember properties instead of handling the QueryRangeData event;
  • Add the FilterBooleanChoice attribute and specify its DefaultValueMember parameter to replace the QueryBooleanChoiceData event.

Expanded Metadata Classes

If your filtering Model changes (for example, they are re-generated when using code-first data sources), your filtering attributes declared in it are lost. To avoid these issues, create a metadata class with public fields and all the required filtering attributes. Then, with the help of the FilterMetadataType attribute, you can share these attributes with your filtering Model. See the 'Metadata Attributes' section of the Filtering Attributes article for an example.

How would you rate this topic?​​​​​​​