Web - How to preserve the FullTextSearch Action filter after opening details for a record and returning back to ListView

I want to repost an interesting ASP.NET WebForms scenario and a solution for it I provided to a customer yesterday. Watch this video to see how this works:

If you are interested in having something like this, check out this Support Center thread for a relatively simple Controller.

Improving UX with Grid List Editors by disabling ALL unsupported operations for non-persistent columns in server modes (XAF v16.2.6) - YOUR FEEDBACK IS NEEDED!

In server modes, grid controls perform operations like sorting, grouping, filtering, etc. on the data store side to guarantee the best performance. Thus, columns bound to non-persistent properties (their values exist only in the client memory at runtime) cannot be used for such server-based operations and can cause exceptions (learn more...). Some of them can be detected only in the end application after navigating to a problematic grid at runtime.

With XAF 16.2.6, to prevent these situations, we have improved column creation logic in our Grid List Editors for Windows and the Web. In particular, we have disabled all server-based operations (sorting, filtering, grouping) for non-persistent properties in the ASP.NET WebForms ASPxGridListEditor and WinForms GridListEditor when DataAccessMode = Server or InstantFeedback. 

Technically, it means the following:

    1) The grid's Find Panel does not take non-persistent properties into account.

    2) The grid's Filter Editor does not display non-persistent properties in the properties tree.

    3) The grid's Auto Filter Row feature is not available for non-persistent columns.

    4) Grid column headers for non-persistent columns do not allow end-users to filter, sort, group.

See this video recorded from the WinForms version of our MainDemo:

Take special note that in XPO, calculated non-persistent properties defined using PersistentAliasAttribute or CalculatedAttribute can still be used without problems for server-based operations as previously. The only PersistentAlias attribute scenario, which may still not lead to disabled server-side operations, is when you have an aliased reference property and a grid column with a complex property path like:
YourPersistentAliasReferenceProperty.SomeNestedProperty1.SomeNestedPropertyN.
Such properties will be treated as regular non-persistent properties for now or you can disable our improvement using the feature toggle below.
For EF, calculated properties defined using CalculatedAttribute are still unsupported and treated as regular non-persistent properties mentioned above.

I do not need this behavior. How do I disable it?
With v16.2.7 (or, after installing this hot fix), you can set the PreventServerSideOperationsForNonPersistentMembers property of the DevExpress.ExpressApp.Editors > ColumnsListEditor  class to False in the overridden OnActivated method of a custom ViewController for a required ListView. Refer to the following example:

[C#]
using DevExpress.ExpressApp;
using DevExpress.ExpressApp.Editors;

namespace MainDemo.Module.Controllers {
    public class S31714_FeatureToggle : ViewController<ListView> {
        protected override void OnActivated() {
            base.OnActivated();
            ColumnsListEditor columnsListEditor = View.Editor as ColumnsListEditor;
            if(columnsListEditor != null) {
                columnsListEditor.PreventServerSideOperationsForNonPersistentMembers = false;
            }
        }
    }
}

[VB.NET]
Imports DevExpress.ExpressApp
Imports DevExpress.ExpressApp.Editors

Namespace MainDemo.Module.Controllers
    Public Class S31714_FeatureToggle
        Inherits ViewController(Of ListView)

        Protected Overrides Sub OnActivated()
            MyBase.OnActivated()
            Dim columnsListEditor As ColumnsListEditor = TryCast(View.Editor, ColumnsListEditor)
            If columnsListEditor IsNot Nothing Then
                columnsListEditor.PreventServerSideOperationsForNonPersistentMembers = False
            End If
        End Sub
    End Class
End Namespace

Filtering - How to search objects within ListPropertyEditor or enabling the standard FullTextSearch Action for nested ListView

Just wanted to repost a nice tip from the old SC ticket, which I updated today:

By default, the standard FullTextSearch Action is mapped to the "FullTextSearch" category or Action Container that is physically present in the main, detail and lookup control templates. Historically, it is missing in the nested frame template, which is typically used for ListPropertyEditor, DetailPropertyEditor or DashboardViewItem, mainly not to overload their toolbar with a large text box.

If you still need full text search functionality in nested frame templates, you can consider the following solutions:

1. Create a custom nested frame template as per the Template Customization. article and manually add the "FullTextSearch" action container into it. This solution appears to be the most difficult from the implementation and further maintenance points of view.

2. Customize the default mapping of Actions to the default Action Containers in the Application Model. To do this, invoke the Model Editor and follow this video:

Take special note that It is important to make a copy of the Action definition and place it into the Action Container (e.g., Link), which is NOT present in the main, detail and lookup control templates to avoid duplication of Actions in the UI:

This solutions appears to be the easiest one from all points.

3. Enable native filtering features of the underlying grid, tree and other data bound controls used in nested ListView. For instance, the Find Panel or Auto Filter Row features also provide very good filtering experiences many of your clients will love.  The only disadvantage (which can be noticeable in advanced scenarios only) is that with the standard FullTextSearch Action you can provide common customizations for root and nested ListView using the events and other extensibility points of our FilterController, while for the native control features, you will likely have to implement platform-dependent customizations.

WinForms GridListEditor - How to restore values in the auto filter row

I wanted to inform you of a recent solution update for this task, which will help you restore auto filter row values for reference properties as well (previously, there might be an exception). The main change is in wrapping the GridView.GuessAutoFilterRowValuesFromFilter call into the using(var criteriaScope = View.ObjectSpace.CreateParseCriteriaScope()) {...} construction, which relies on the smart DevExpress.Data.Filtering > CriteriaOperator > UserValueParse event  handling inside our XPO/EF core libraries: 

using System;
using DevExpress.XtraGrid;
using DevExpress.ExpressApp;
using DevExpress.XtraGrid.Views.Grid;
using DevExpress.ExpressApp.Win.Editors;

namespace MainDemo.Module.Win {
    public class B152594 : ViewController<ListView> {
        GridListEditor gridlistEditor = null;
        protected override void OnViewControlsCreated() {
            base.OnViewControlsCreated();
            gridlistEditor = View.Editor as GridListEditor;
            if(gridlistEditor != null) {
                gridlistEditor.Grid.HandleCreated += Grid_HandleCreated;
            }
        }
        private void Grid_HandleCreated(object sender, EventArgs args) {
            GridControl grid = (GridControl)sender;
            grid.HandleCreated -= Grid_HandleCreated;
            using(var criteriaScope = View.ObjectSpace.CreateParseCriteriaScope()) {//!!!
                ((GridView)grid.MainView).GuessAutoFilterRowValuesFromFilter();
            }
        }
    }
}

After you modify the filter either by manually typing values in the topmost grid row or visually via the filter builder and reopen the form, there will be the following result in the UI:

I think your end-users will appreciate this functionality and I would be grateful to hear from you on how this works in your apps and whether there are any uncovered scenarios. Thanks! 

How to hide or filter out certain types from the drop-down editor for the System.Type properties

I want to share my recent article on the subject that demonstrates yet another example of how flexible and powerful XAF really is. There, I will describe three possible ways of accomplishing the same task, starting with the most recommended platform-agnostic solution at the business model level (write once, work everywhere) and finishing by manipulating end control properties in the UI for certain platforms and contexts. 

So, let me quite myself from this KB article in our Support Center:

Implementing cascading lookup editors with the @This parameter

It is quite common to filter one combo box data source based on the value selected in another drop down editor. For instance, imagine a Country/City scenario, demonstrated in our ASP.NET demos here (remember the amount of code lines for this demo). 

eXpressApp Framework (XAF) allows you to write less code for such common scenarios with the help of various data annotation attributes, configurable application UI metadata, built-in modules and their Controllers. Specially for this particular scenario in XAF we have the Current Object Parameter (@This) feature, which can be used in the criteria set for the lookup's data source via DataSourceCriteriaAttribute. For instance, if there is an Order class with the Product and Accessory reference properties, you can implement the latter property as shown below (just a single line) to have it filtered by the selected product (assuming that the Accessory class has a back reference to the Product class):

    [DataSourceCriteria("Product.Oid = '@This.Product.Oid'")]
    public Accessory Accessory { ... }

Here the '@This.Product.Oid' part refers to the properties of the Order object opened in the DetailView. So, this functionality is available only in the context of the View with an object in it and is technically provided through patching the criteria string and replacing the @This part with the actual value.

JFYI for creators of custom PropertyEditors for complex ListView in-place editing scenarios in WinForms

This is just a quick note for advanced XAFers creating complex PropertyEditors in WinForms.

If your custom PropertyEditor is intended for complex ListView in-place editing scenarios (e.g., drop-down editor data source filtering), then its underlying control should support the DevExpress.ExpressApp.Win.Core.IGridInplaceEdit interface.

The most common scenarios include data source filtering (e.g., the functionality of the DataSourceCriteria, DataSourceProperty and similar attributes) and obtaining information of the currently edited record in ListView for internal purposes (e.g., obtaining object type information). Standard XAF PropertyEditors whose underlying controls implement the IGridInplaceEdit interface include LookupPropertyEditor, ObjectPropertyEditor, PopupCriteriaPropertyEditor and ExpressionPropertyEditor. You can refer to their source code for more details. In addition, you can consider checking the How to work with referenced properties via a simple drop down list instead of the standard LookupPropertyEditor (Example) example source as well.

Checking if an object is new or not within a criterion string

Typical usage scenarios

I remember registering a corresponding feature request in order to make it easier for XAF developers to accomplish the following types of tasks:
a) Validating data fields for new records only; e.g., the scenario from Q440548
b) Implementing different data field appearance for new and saved records; e.g., the color or enabled state as in Q475272
c) Managing Action controls' state for new records via TargetObjectsCriteria

During these years these three scenarios stayed popular among our users (we had several dozens of trackers), so it was a natural decision for us, as framework creators, to make accomplishing this common and proven stuff easier for developers and probably end users.

Meet the new DataSourceCriteriaProperty attribute - another addition to the unlimited XAF filtering capabilities

Another example where you asked, and we have listened and implemented.

From Core - Make it possible to specify a dynamic criteria for lookups in code of business objects (similar to DataSourcePropertyAttribute):

"We have implemented a new DataSourceCriteriaPropertyAttribute attribute in 12.2. You can apply it to collection and reference properties (of course, you can also set it for the class member, ListView column or DetailView item in the application model) to filter them, similar to other standard DataSourceProperty and DataSourceCriteria attributes that work in this scenario.
The only difference is that the constructor of this attribute accepts a string name of the property of the CriteriaOperator type. This capability allows you to *dynamically* perform custom filtering of almost any complexity, and that works in the server mode (which is not always possible when DataSourcePropertyAttribute is used)."

You can find more information about the concrete business scenarios where this new attribute can be used in the ticket above. Hope you liked this small addition to the framework.