Microsoft introduced a change in Dynamics AX 2012's List pages that meant that X++ can no longer be written directly on the form. This was, in part, to help provide a more seamless experience between the web interface (Enterprise Portal) and the Windows client.

One drawback of this is that the old method of using edit methods to add quick filters to a list page could no longer be used, as edit methods must run on the form if they are to access any data source other than the current record's form data source.

Microsoft obviously solved this and provided a new method to add custom filter controls. This, in many ways, is better than the previous method, as it does not require us to write code.

A list page created from the form template is made up of an action pane, a custom filter group control, and a grid.

When we add form controls to the Filters group control, they get three new properties:

The first two properties define the field that the filter applies to, and the third property is the filter. The expression %1 means the value the user entered. Setting the FilterField property and leaving FilterExpression at its default value of %1 will simply filter the field by what the user enters.

AX does this in the same way as we construct a QueryBuildRange object against the data source, which means that the user can use wildcards and value ranges. This is fine for simple filters, but sometimes, we need to introduce more intelligence. Again, we can do this as we can treat it as a QueryBuildRange object.

Some examples of useful expressions are as follows:

You can also be very creative with FilterExpression, but this can become hard to read; keeping it simple is important.

In order to add a simple filter to a list page, follow these steps:

Entering a partial match now returns all vehicles that contain the string entered.