Web - How to avoid issues with data-bound controls due to missing or non-unique key values

Check out the Web - How to avoid issues with data-bound controls due to missing or non-unique key values KB article to make sure that your business model is aligned with the best practices. Here is a short extract:

Symptoms

You may notice the following side-effects in a Web ListView while it may work fine in WinForms:

- A wrong DetailView may be selected when an unsaved record is clicked in ListView;

- ListView may have no selection column;

- In inline edit or batch mode, all records may become selected or editable.

These effects are especially frequent in a non-persistent class ListView or a nested ListView for an aggregated details collection with newly added or unsaved records.

Explanation

All new records added to the ListView and not yet saved to the database will be assigned with a temporary key value (e.g. -1 or an empty Guid/String value depending on your key type). In a Web application, ListView uses a business class key property to identify records, because there is no way to access real business objects from the web browser. Hence, there is a requirement that each business object must have a unique value assigned to the key property. ASPxGridView and other data-bound controls require this for the correct operation of such features like selection, filtering, sorting, grouping and the standard XAF functionality that depends on them (see also ASPxGridBase > KeyFieldName). 

If a key property is missing in a business class completely or if a key property is not initialized with a unique value immediately after the record is created, these duplicate or invalid records may lead to a data-bound control malfunction as expected.

Please inform me of your health-check results!

Improved diagnostics for ListView errors in Server Mode

From the Core - ListView shows blank rows or freezes in certain scenarios in Server Mode ticket:

In certain scenarios, a list view with DataAccessMode set to Server may show empty rows or operate slowly. This behavior is usually caused by exceptions thrown during data loading that are handled internally. Such situations can be diagnosed using the debugger (see What to do when the grid displays blank rows in Server Mode and ASPxGridView displays empty rows when bound via Server Mode).

Starting with v18.1, we improved the XAF built-in diagnostics for errors occurring in Server Mode data sources. Now, server-side errors (intercepted via the ServerExceptionThrown event) are written to the application log. In addition, when the log level is set to 4 (Verbose), errors reported via the InconsistencyDetected event are also written to the log. While the latter event doesn't always indicate a problem, the error message may be helpful in researching the cause of performance issues.

ASPxGridListEditor - How to customize the column chooser of the Web ListView's grid control

I wanted to promote the article that shows how to  increase the ASPxGridView's customization window size, because last week there were two requests for this + I searched around a dozen tickets in both XAF and ASPxGridView knowledge bases on the same subject. 

https://www.devexpress.com/kb=Q553446

Previously, it was possible for developers to hard code the required width and height for this window.

Around v17.1, the ASPxGridView team created the AllowResize option (based on feedback from XAF users mostly) so that end-users could resize this dialog as they wish at runtime.

Currently, the AllowResize option is set to False by default, because the ASPxGridView team is afraid of breaking existing customer projects.

EDIT: The ASPxGridView has implemented AllowResize = True in v17.2 RTM by default.

I am looking forward to hearing from you on whether you or your end-users ever had problems with this so that our both teams can take this into account regarding future product updates. Thanks.

XAF ASP.NET WebForms - Beware of the FormatException (Input string was not in a correct format) when clicking a record in a popup ListView

I want to draw your attention to the T514321: ASPxGridListEditor - FormatException is thrown when selecting an object in a lookup ListView shown from an aggregated collection issue, which is already fixed in XAF for v16.2.7/17.1.4. 

If you came across a similar issue (check the call stack), the highlighted thread contains the hotfix installation for v17.1.

Tip:

When you experienced an exception in DevExpress code, I recommend you locate its callstack and search for one or several topmost method names in our support database, because this behavior might be reported by someone else: https://search.devexpress.com/?q=ASPxGridViewContextMenu.SelectObject&m=SupportCenter

In addition, I recommend checking the Known Issues sections in our What's New documentation:

    all XAF issues that were created in v2016 vol 2.6.

    all XAF issues that were created in v2017 vol 1.3

How to hide the New Action from the main menu, but still have it available inline as the New Item Row feature of ListEditor

I would like to promote a Support Center article on the subject, which I heavily updated with new code examples and implementation considerations after receiving a similar customer request yesterday.

As I found later when searching our support database, many users wanted this specific customization in nested ListViews, mainly not to overload end-users with a separate root DetailView in this inner context. I must say that I saw similar reasoning for MasterDetailMode = ListViewAndDetailView too (for this scenario, we offered a solution like this one).

I personally prefer the 2nd solution from this article, but I must admit that both solutions could be simpler, ideally. Please let our team know if you experienced a similar need and clarify exactly where and why as well as how you are solving it now. With that, we will be a better position to consider further improvements. Thanks in advance, guys!

Improved ASPxGridListEditor performance when selecting records in the grid control

Starting with version 16.2.7, we improved the selection behavior of ASPxGridListEditor. Currently, ASPxGridView does not re-render itself when selection is changed. 

See screenshots of the Network tab in Chrome Developer Tools (F12) that demonstrates how the size and time of a response in the Opportunity_ListView of the XCRM demo is reduced. The size and time of a response is reduced about 4 times and 35% respectively.

v16.2.7, 17.1.3+

v16.2.6 and lower

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

ASPxGridView/ASPxGridListEditor + Server Mode + Select All = ?

I want to pay your attention to this Support Center ticket describing a recent fix for our ASPxGridListEditor, which is a wrapper over the ASPxGridView component as you know.

It is a known and pretty logical Server Mode limitation that the selection of ALL grid rows using the built-in SelectAll check box is NOT supported in this mode. That is because this particular operation defeats all server mode benefits = causes loading the whole data source into the web server memory...

Our ASPxGridListEditor did not manage the "Select All" header cell visibility prior to v16.2.4. We have corrected this mistake and now this button is hidden in server mode by default (SelectAllCheckboxMode = None). The "Select All" button is still available in Client and DataView modes only (SelectAllCheckboxMode = AllPages), though.

If you want, you can implement a custom Controller from the ticket to enable selection of all records on the currently active page only when DataAccessMode = Server (we did not follow this route in the XAF code, because it would be more confusing and even damaging for users who got used to this command). Alternatively, you can set DataAccessMode = Client/DataView  for a required ListView node using the Model Editor (of course, it you do not have many data records).

If these solutions do not help, please describe your real life use-case scenario where this SelectAll feature is needed when grid is operating in server mode. It is possible that we have an alternative and even better technical solution for you, e.g. like we did for Reinhold and his reporting scenario.