I'm trying to filter a grid in Server using Infragistics.Web.Mvc.FilteringExtensions and the "Where" function.
When de expression ("Expr" in FilterExpression object) is a double value I have a problem.
If "Expr" is "31.55", the "Where" function applies the "3155". And if "Expr" is "31,55", the "Where" function thow a exception.
in Infragistics.Web.Mvc.ExpressionParser.Parse(Type resultType)in Infragistics.Web.Mvc.DynamicExpression.ParseLambda(ParameterExpression parameters, Type resultType, String expression, Object values)in Infragistics.Web.Mvc.FilteringExtensions.Where(IQueryable source, String predicate, Object values)
I invoque "Where" function:
data.Where("ask_precio.Value > 30.23", new object})
How can I apply this filter?
Thank you for posting in our forum.
The Where() method in Infragistics.Web.Mvc throws this error because it tries to find a column with a key of “ask_precio.Value”. In case your columnKey is “ask_precio”, try removing the “.Value” and check if this would resolve the problem.
There is a detailed help topic that covers handling the remote Filtering manually on the server. It contains a code snippet which uses the Where() method when filtering the data using the expressions from the query string. You may read it here:
If you need any additional assistance, feel free to contact me.
I'm using "handling-remote-features-manually#filtering" solution.
The problem isn't a ".Value", because with a integer expression works well. I have tried removing ".Value" and the error is the same.
I add the ".Value" because the property "ask_precio" is nullable double (double?).
I was able to reproduce this issue on my side. It seems to be related to the Spanish localization settings that you use, which change the decimal separator to a coma instead of a dot. Converting the value in the expression string to a type Double ignores the dot in that case, as it is not considered a valid character, and just concatenates the rest of the digits – thus you get an incorrect integer. Trying to change the separator to a coma would produce an incorrect expression, because the extended Where() method expects a number with a dot as a separator.
I am currently investigating if there is some way to workaround this problem – I will keep you posted of any available information.
Thank you Vasil!
I have investigated your issue, and I have asked our engineering staff to examine this further. To ensure that it will receive attention, I have logged this behavior in our internal tracking system with a Development ID of 261227. The next step will be for a developer to review my investigation and confirm my findings or to offer a fix, or other resolution.
I have opened a support case, which you may see on the web site - you can view the status of the development issue connected to this case by selecting the "Development Issues" tab there.
Thank you Vasil.
Now, before "Where" function I change the "Culture" to "en-US" and after I return to the previous "Culture".
I am glad that you have been able to find a possible workaround for the problem.
Please let me know if you have some additional questions regarding this matter.