Hi Peter,

I apologize for the inconvenience. We prioritize items based on multiple factors, one of which is its popularity. Given the amount of attention this item has attracted, it is very likely we will include it in our planning. Lastly, the best way to get notified for its status is to follow this thread.

Regards,
Radko
Progress Telerik

Hi Alexander,

In order to explain why the Is null and Is not null operators appear, I should include a few details of the current implementation.

One specific is that the current implementation always includes the IsNull and IsNotNull operators, despite whether the the bound type is nullable or not. We have a public bug report about this, which once resolved, will omit the above-mentioned operators if the bound type is non-nullable. Here is a link to the item, where you can cast your vote if you see value in it: https://feedback.telerik.com/blazor/1481544-non-nullable-numbers-still-get-the-isnull-and-isnotnull-filter-operators

Another specific is that the internals currently rely on resolving filter operators for non-nullable types only. As for how the type is determined - whenever a filter is requested, the column decides what operators to use based on either the underlying type of the Field parameter(if such is provided), or the FieldType parameter, which is taken as-is. Due to this specific, operators are properly populated for nullable fields in non dynamic configs(which is when the Field parameter is used mostly anyway), but are not for nullable types passed to FieldType(which is often used when the Grid is bound to dynamic objects). Because of this, when using FieldType, correct filters are resolved only when the passed type is non nullable - in all other situations, a set of default operators are used, which are the standard ones for the type string, thus not applicable for a numeric value.

As for a potential workaround - would it be possible to use non-nullable types and instead define a cell template, similar to what Kristian has suggested earlier in this thread? The template will allow to correctly format the value within the cells(e.g. do not show anything if value is null), but should set the correct operators, due to the specific I outlined above. If this is not an option, would you be willing to share more details for your exact use-case, so I can better understand the scenario? Thank you.

Regards,
Radko
Progress Telerik

Hello Stefan,

The best way to keep in track with the progress of this item is to follow it - this way you will receive updates as soon as its status changes. Besides this, one could cast their vote to raise the item's popularity, but I see you have already done this.

In the meantime, I have provided a plausible workaround in a previous reply - have you tried using it while waiting for a fix?

Regards, Radko Stanev Progress Telerik

Hello Meindert,

A possible workaround for this is to take control of the creation of the FilterDescriptor objects associated with the problematic nullable fields of the ExpandoObject. This could be achieved through a FilterMenu template (refer to FilterRow template if this is what you are using) for the given column. Through this template, you can set the appropriate descriptor's MemberType property to correctly reflect the field you are filtering on. I have attached an example that demonstrates my idea. Note this is a rather basic example, and filter value setting/resetting is not properly implemented.

Note this would require defining your own filter template, including setting available operators and so on, but hopefully should suffice as a workaround until a fix is provided.

Regards, Radko Stanev Progress Telerik

Hi Meindert,

Thank you for the clarification. Indeed, I was able to reproduce the described behavior following the steps you have provided. After having a look, I can confirm this to be the same issue as discussed in this thread already, which stems from the way the DataSource package works with Expandos and nullable types.

I can see you have already voted for its fix and as you are following the thread, you will automatically receive notifications about its progress.

Regards, Radko Stanev Progress Telerik

Hi Meindert,

If I understand correctly, you had to introduce nullable types in order to get the aggregates to work correctly? 

The above-described issue stems from the nullable types themselves and if there is no need for such, the Grid should pick up the correct FilterOperator by itself. We have an example (https://github.com/telerik/blazor-ui/tree/master/grid/binding-to-expando-object) that demonstrates binding to Expando, grouping with aggregates that might be helpful.

If I misunderstood, could you please elaborate more in regards to why nullable types were needed for the aggregates to work?

Regards, Radko Stanev Progress Telerik

Hello Rayko,

Thank you for the additional information you provide.

I dug more into the case and you are absolutely right - It's a filter issue and the main limitation comes from the way our DataSouce abstraction operates with expando object properties.

I also found that it's possible to extend the current implementation to support nullable value types, so I'm changing the status of the Feature Request to Unplanned and you can Follow its progress on this page.

Regards,
Kristian
Progress Telerik

Hi Rayko,

Thank you for this feature request.

You are right that it will be really useful if binding the Grid to ExpandoObject could handle nullable types automatically.

We need to investigate deeper if this is doable with the current implementation, though. 

I will gather more information and I will follow up to you and to share the results of the investigation.

Until then, I can offer you an easy workaround to show the null values in the columns:

Define templates of your columns that showing the value directly from the current expando object. Here is some sample code:

<GridColumn Field="Age" FieldType="@typeof(int?)">
    <Template>
        @(((IDictionary<string, object>)context)["Age"])
    </Template>
</GridColumn>

Regards,
Kristian
Progress Telerik