Minor improvements to the Web editors for image and reference properties

Starting with version 17.1.6, we simplified access to the internal upload control of the ASPxImagePropertyEditor, because several users wanted to tweak it. Here is the KB Article showing how to access ASPxImagePropertyEditor's ASPxUploadControl and customize it to set the maximum file size and allowed file extensions for the uploaded images:

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

Starting with version 17.1.6, we added the static DefaultViewModeBehavior property and the ViewModeBehavior property to the ASPxObjectPropertyEditorBase class (the base class for ASPxLookupPropertyEditor and ASPxObjectPropertyEditor used for reference properties).

To globally disable or show links, we recommend using the static ASPxObjectPropertyEditorBase.DefaultViewModeBehavior property instead of the former ASPxObjectPropertyEditorBase.ShowLink property. For instance, you can do this in the YourSolutionName.Web/Global.asax.xx or WebApplication.xx files:

static MainDemoWebApplication() {

            DevExpress.ExpressApp.Web.Editors.ASPx.ASPxObjectPropertyEditorBase.DefaultViewModeBehavior 

                = DevExpress.ExpressApp.Web.Editors.ASPx.ObjectPropertyEditorViewModeBehavior.ShowLabel;

If it is necessary to disable or show links in a specific situation, you no longer need to inherit a custom property editor from ASPxLookupPropertyEditor; just get access to the required PropertyEditor (see Access Editor Settings) and set the ViewModeBehavior property to the ShowLabel or ShowLink value. 

Controller creation performance optimization v17.2 Preview - YOUR FEEDBACK IS NEEDED!

Starting with version 17.2, we've further optimized the process of creating Controllers that should positively affect forms loading performance and thus overall end user experience, especially in very complex detail forms.  In addition to List Property Editors (learn more about v17.1 improvements in this regard), Detail, Object and Lookup Property Editors, DashboardViewItem and popup windows created in a special way were supported. We are publishing this KB article prior to the 17.2 release to collect early user feedback and improve the overall stability:

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

If you are an active v17.1 subscriber and want to test this feature with your real world applications on a virtual machine (or another suitable test environment) prior to the official release, please leave a comment to this KB article or rather create a separate private ticket, so that we can verify your account and provide you with a v17.2 preview installation privately.

We would appreciate your thoughts and feedback once you've had the opportunity to try this new feature in your upgraded v17.2 project. Please report any issues and suggestions in our Support Center. Thanks for your help in advance!

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

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.

Using a built-in lookup editor based on values from another table for editing simple property types

This is actually a variation of a solution I described in my recent A very interesting way to update and display a persistent property via a non-persistent one post, because it is again based on a non-persistent reference property filtered using the DataSourcePropertyAttribute along with a custom data source collection.
This non-persistent reference property is represented using the standard XAF's lookup PropertyEditors, which are quite convenient for providing a user with the capability to select a single value either from a database table or from an arbitrary data source. In one turn, by adding custom logic to the getter and setter of our non-persistent calculated property, we can update the stored persistent value, which does not need to be a reference to another persistent class (table), but to any type (e.g., string or integer). This may come in handy for legacy databases when you cannot really modify the schema to provide normal associations between tables.

Let's take a look at the actual code for this solution:

Update to a custom lookup editor for working with referenced properties via a simple drop down list

I have just updated one of my Code Examples that shows how to work with referenced properties via a simple drop down list instead of the standard LookupPropertyEditor. Technically, I built a custom WinForms Property Editor that is based on the LookUpEdit control from our XtraEditors library. This is what it looks like:

Today in addition to some minor refactorings and bug fixes, I added a button that enables you to open the associated record directly from the editor + localizable tooltips for other editor buttons.

BTW, I think that a similar feature would be helpful for the built-in LookupPropertyEditor, since it is more visible to end-users than a magic Control+Shift+mouse click shortcut. Plus, a similar feature already exists in the Web version.

Feel free to download this update, report bugs (if any) and let me know your other thoughts on this.

How to easily prevent clearing a lookup field value?

This post is devoted to one more usability improvement in version 13.2: 

Usability - Make it possible to hide the Clear Action via the application model

In particular, our customers wanted to make it possible to easily hide the Clear Action in lookup Property Editors and thus disallow end-users to clear values for certain fields.

Previously, it was already possible to implement this task in code, but it required writing two platform-dependent Controllers. For instance, in WinForms you could find the LookupWindowController and deactivate its ClearAction in code. As for the Web, you could find a required ASPxLookupPropertyEditor and update the ClearingEnabled property.

Now we simplified it to setting a single AllowDelete property for a required LookupListView node via the Model Editor:

Take special note that after this customization in WinForms app your end-users will not be able to leave the lookup value empty via the Control+Delete shortcut supported by our XtraEditors.

Of course, this also works on the Web:

Although this is not the only way to implement this scenario (e.g., you could also use validation rules here), I hope you liked this small usability improvement. Please let me know your thoughts in comments.