This started after I upgraded recently. I'm using 20.3.0.47.
So, for my one table I'm using SfDataGrid and using ExpandoObject. I'm populating one field with Double values except I was defaulting the value to 0 which was technically an int32 since I didn't use 0d. When doing that and trying to sort a column I was getting the error I have attached. Basically it can't compare Object to Double.
Obviously, I can fix the problem but I figured I'd mention it. It seems like something common that people might do and comparing double to int shouldn't be a big issue and it had worked before.
We have checked the
reported issue with the mentioned version (20.3.0.47). Here, we have attached the tested sample and a video demo
for your reference. Please have a look at this. Could you please confirm if we
missed anything?
Here's how I reproduce it. I'll attach a project example. I just add an SfDataGrid to XAML and dynamically add a column and some data.
var column = new GridNumericColumn
{
MappingName = "Test",
HeaderText = "Test Column"
};
dataGrid.Columns.Add(column);
var list = new List<IDictionary<string, object>>();
var row = new ExpandoObject() as dynamic;
row.Test = 5.5;
list.Add(row);
row = new ExpandoObject();
row.Test = 10.0;
list.Add(row);
row = new ExpandoObject();
row.Test = 0; // changing to 0d works
list.Add(row);
dataGrid.ItemsSource = list;
Currently, we can reproduce the reported issue. In the initial update, you mentioned that you were facing the reported issue after upgrading only. So, could you please share the Syncfusion version that was used previously? Without facing the reported issue, it will be helpful for us to check on it and provide you with a solution as soon as possible.
It had been a while. I was using 20.2.0.36 before updating.
We have checked the reported issue on our end. In that, we have used the
OrderBy method to sort the records. When you are performing the sorting
operations with mixed datatypes the reported problems occur in the framework
itself. By default, if you need to sort any column you should populate it with
the same datatype values. However, You can overcome the reported issue by using
the “0d” as you mentioned.
Yeah it's not a big problem. I only had to make 1 small change. Just thought I'd mention it as it seems like something that could be handled and did used to work. Maybe there's some overheard but the LINQ .Cast<columnType> or something
No, you can overcome the reported issue by using “0d”
which is good enough. If you are satisfied with our response, please mark it as
an answer. Otherwise, please let us know if you have any further queries on
this. We are happy to help you.