I obsoleted the IModelListViewWin extension in 13.1 and moved its properties into the core IModelListView interface. Starting with that version the Web Grid and Pivot List Editors will also support setting the active filter functionality. Technically, that means that every List Editor that supports this will implement the following interface:

namespace DevExpress.ExpressApp.Editors {
    public interface ISupportFilter {
        bool FilterEnabled { get; set; }
        string Filter { get; set; }
    }
}

For instance, in the simplest case (ASPxGridView) the implementation can look like this:

        bool ISupportFilter.FilterEnabled {
            get {
                return Grid.FilterEnabled;
            }
            set {
                Grid.FilterEnabled = value; ;
            }
        }

        string ISupportFilter.Filter {
            get {
                return Grid.FilterExpression;
            }
            set {
                Grid.FilterExpression = value;
            }
        }

BTW, the IModelListViewWeb.FilterExpression property was obsoleted as well.

While the majority of you are unlikely touched any of those types and properties in your custom code and thus you, developers, will unlikely be affected by these changes, your end-users quite likely customized filters in your apps. Will they be affected? Hopefully, NOT!

Since we are good developers and think of our end-users, I of course ensured that their filter customizations are not lost with the new version. In order to do this, I followed the Convert Application Model Differences help article and implemented the IModelXmlConverter interface (honestly, it was already implemented there because there were already a few conversions related to templates) in our System Windows Forms and ASP.NET modules. For instance, this is how it looked in case of the Windows Forms module:

if (parameters.XmlNodeName == "ListView") {
                string oldProperty1 = "ActiveFilterString";
                string oldProperty2 = "IsActiveFilterEnabled";
                string newProperty1 = "Filter";
                string newProperty2 = "FilterEnabled";
                if (parameters.ContainsKey(oldProperty1)) {
                    parameters.Values[newProperty1] = parameters.Values[oldProperty1];
                    parameters.Values.Remove(oldProperty1);
                }
                if (parameters.ContainsKey(oldProperty2)) {
                    parameters.Values[newProperty2] = parameters.Values[oldProperty2];
                    parameters.Values.Remove(oldProperty2);
                }
            }

I am lucky enough that my real case was rather academical, but if you have a more complicated scenario, XAF also has a solution for you. You can learn more about it in the end of the aforementioned help article.

To sum this story up, it is always best practice to preserve your end-users settings as much as possible with the new version, because their data is one of the most important things and dealing with it carefully will ensure they will like your application in the end.

 

So, if you provided custom application model extensions (e.g., there a lot of them in our community project - eXpand that is designed to reduce the amount of code (check this demonstration to learn more) to achieve something) and need to change them, always think about providing a converter like the one above.