[Solved] Filtering Issue in RadGridView

[Dave]

I've run into this problem and am wondering if there's a simple resolution or if I have to just create my own filtering dialog to handle this.

I'm binding my grid view to a collection of objects. One of the columns I want to bind to is my own custom class called Date, which is basically just a formatted DateTime value with some custom validation and error checking. I set up the column binding like follows:

column.DataType = typeof(DateTime);
column.DataMemberBinding = new Binding("Date.DateTime");
column.DataFormatString = "{0:MM/dd/yyyy}";

So, I have a DateTime property on my Date class that exposes the converted DateTime value and I'm binding my column to that. However, when I attempt to filter, doing anything but a "Less than" filter on a date causes the grid to filter out every record in the grid when there should be some remaining.

Should filtering be working with this type of setup?

[Rossen Hristov]

Hello Dave,

I am somewhat confused. If the property Date.DateTime is of type DateTime, then how can it be formatted. When something is formatted it becomes a string. So if Date.DateTime is a string, then column.DataType = typeof(DateTime); is wrong, because the values that the column is displaying are strings and not DateTimes.

If Date.DateTime is of type DateTime, you should be able to filter correctly. The actual filtering is always performed on the "raw" values, i.e. the raw DateTime's before they are formatted for the user's viewing pleasure. The strings that you see in the distinct values list box are just for UI purposes only. Beneath each nicely formatted string, sits the actual raw DateTime which is used when performing filtering against the source collection.

In case you think that you have found some kind of a bug, could you please send us a very little dummy project with your exact setup and we will investigate it immediately.

Thanks in advance.

Best wishes,
Ross
the Telerik team

[Dave]

The Date.DateTime is in fact type DateTime, not string.

I think I figured out the cause of the issue though. The way I'm binding the GridView columns is actually through an indexer that returns an object reference. In this case, that object reference is of type Date. So actually my binding on this column looks more like this:

column.DataMemberBinding = new Binding("object.DateTime");

This is clearly confusing the filtering control (the distinct filter list simply displays "01/01/0001"), even though everything else displays fine. Is there any way around this? Perhaps a converter I can apply to change the object reference into a hard Date reference?

[Rossen Hristov]

Hi Dave,

Unfortunately, I still can't quite figure out what exactly is going on.

The fastest way to resolve this question would be to send me a small dummy project that demonstrates what you are doing and I will take a look at it to see what's happening.

I am looking forward to hearing from you.

Greetings,

Ross
the Telerik team

[Dave]

Here's the attached project. As you'll see, I do my binding through an object indexer. I included a Date to DateTime Converter class and tried using that but the filtering still won't work. It obviously has trouble handling the object reference because when I make a Date property and bind to that, it will work fine. However, this is not an option on my project.


http://www.telerik.com/ClientsFiles/289938_GridViewColumnTest.zip

[Rossen Hristov]

Hello Dave,

I debugged the sample project and you are right -- the fact that the indexer is of type object breaks the chain between the Date class and its DateTime. When we perfrom sorting, filtering and grouping, we create LINQ expressions. Some of them are member access expressions. So for example for the string "[BirthDate].DateTime", we will tokenize it and create an indexer LINQ expression and the property accessor LINQ expression. Since the type of [BirthDate] is object, we can't continue and create a property accessor LINQ expressions, since object does not have a property called DateTime.

For the time being, your only option would be to use "normal" binding, since this indexer+dot combination fools our data engine.

I will start thinking of a way to overcome this and I will let you know if I manage to think of something.

My idea is that if I change the way we generate our LINQ expressions, you should be able to bind your column to "[BirthDate]" only. If your Date class implements the IComparable interface (which it does) you will get sorting out-of-the-box for this type. You will also get the IsLessThan, etc, kinds of filtering on this class. If your Date class has Equals and GetHasCode overrided -- you get IsEqualTo filtering and distinct values. So the general idea is to make your class very "comparable, equatable and so on" and then I will try to make our data engine generate expressions that benefit from this fact. Because for example, right now if you create a LessThan filter it will produce something like source.Where(date < 08.01.2011) which will not work, because your Date class does not have the < operator overloaded. If I change our data engine to do this source.Where(date.CompareTo(08.01.2011) < 0), then it will take advantage from the fact that your class implements all of these nice interfaces. Therefore, your custom class Date will become sortable, filterable and groupable thanks to these contracts that it meets.

I will start researching the options for changing our expression generation logic and I will let you know when I have more information. I will leave this support thread as "Requires additional answer" and I will contact you when I have something.

Regards,
Ross
the Telerik team

[Dave]

Thanks for the quick reply. So, currently, I could have filtering/sorting on my custom class if I bind directly to [Birthdate] and then override all of the operators?

[Rossen Hristov]

Hello Dave,

Yes, if your class has Equals, GetHashCode, <, >, <=, >= overridden you should be able to sort and filter on it.

But I need to make some changes so that the filter operators such as IsLessThan, IsLessThanOrEqual, and so on, i.e. the comparison ones, appear in the filtering UI, because currently they are available only for a short list of types. My plan is to check whether the type supports comparisons at runtime and if it does, I will show the comparison operators.

I'll start working on this task today and I will let you know once I have an unofficial build for testing purposes.

Thank you for your understanding.

Best wishes,
Ross
the Telerik team

[Rossen Hristov]

Hello Dave,

In case you are in a real hurry and you can't wait for my fix, you can override the comparison operators as we formerly discussed and then manually change the available FilterOperators that the FilteringControl displays. You can do this by creating a custom FilteringControl that derives from our stock FilteringControl and then change its available filter operators like this:

public override void Prepare(GridViewBoundColumnBase column)

        {

            base.Prepare(column);

            var availableOperators = new List<FilterOperator>()

            {

                FilterOperator.IsLessThan,
FilterOperator.IsGreaterThan,



                FilterOperator.IsEqualTo,

                FilterOperator.IsNotEqualTo,  

                //..and so on

                

            };

  

            var cbo1 = this.ChildrenOfType<RadComboBox>()

            .Where(b => b.Name == "PART_Filter1ComboBox")

            .FirstOrDefault();

            cbo1.ItemsSource = availableOperators;

  

            var cbo2 = this.ChildrenOfType<RadComboBox>()

            .Where(b => b.Name == "PART_Filter2ComboBox")

            .FirstOrDefault();

            cbo2.ItemsSource = availableOperators;

        }

Here is my blog about custom filtering controls.

Greetings,
Ross
the Telerik team