The data sources implement IDisplayNameProvider in order to format "CamelCase" names as "Camel case".
When you create a calculated field, the designer forces all the field names in the expression to the display name version: [CamelCase] gets replaced with [Camel case].
Then when the report is generated, the CamelCase field is never read . The report generator tries to read a property called "Camel case" and finds it doesn't exist and null is always returned.
If the report designer auto formats the names to the display name version (which I like), why does it not understand how to read the display name version?
Hi Joseph,
I have reproduced the issue using the attached sample project (see the video) and forwarded it to our developers, so they can examine it thoroughly. This might take some time for us. Your patience is highly appreciated.
Guys, your hotfix partialy fixed problem with calc fields. New fields that are inserted work OK, but old ones have to be deleted and recreated again.
Hi Goran,
Yes, I see the issue. Our developers will examine this behavior further. I will get back to you once we have any results.
This problem is still only partially fixed. The expression editor gets confused with aggregate expressions when you double click in the field list, and the same "Camel case" property reading issue happens in the aggregate filter operand and the aggregated value operand.
Hi Joseph,
We have just published a hotfix for this issue. Would you please redownload it and let me know your results?
I installed it. I don't see a difference in behaviour. Specifically, when you have an aggregate operator expresssed as:
[Detail collection][[Some property] < 10].Sum([Another property])
The operator still fails to evaluate unless you manually CamelCase the two detail properties:
[Detail collection][[SomeProperty] < 10].Sum([AnotherProperty])
The expression editor UI is still confused also. To see, start a new expression and double click a child relation's name. The expression editor will correctly insert:
Then go to functions and double click Sum:
2a. [Detail collection][].Sum()
Then place the cursor inside the parentheses and double click a detail collection property. The editor incorrectly inserts:
3a. [Detail collection][].Sum([Detail collection.Another property])
The same issue occurs inside the filter brackets.
By comparison, if you manually correct it initially to camel case:
2b. [DetailCollection][].Sum()
Double clicking the child property results in:
3b. [DetailCollection][].Sum([AnotherProperty])
Which is a step ahead- in that it actually returns a value when it is used- but it should not require manual modification and it should allow the use of custom names inside the parentheses and filter brackets.
In other words, at step 2a, double clicking should result in [Detail collection][].Sum([Another property]), and that exact expression string should evaluate at runtime when displaying the report.
We are working on your request, but it can take us some time to examine it. I will get back to you once we have any results or need additional information. Thank you for your patience.
Again, the problem is not fixed in this hotfix. We created a ticket for the same issue: https://www.devexpress.com/Support/Center/Question/Details/Q556355
In this ticket we have a sample project with the problem in it. After this hotfix the problem is still the same. No difference, no fix.
I hope the problem is clear to you and you could fix this problem.
At this moment we cannot upgrade to 13.2 because all our customers are using reports with calculated fields.
There is still a problem with the aggregate operator in the expressions. We are working on a solution.
It seems that the expression editor UI issue isn't related to the current thread, so I created a separate ticket Expression editor - A field is inserted incorrectly for an aggregate function if display names are specified.
As for the Vekrasoft question, the situation is more complicated in this case and will be discussed in the Calculated fields don't work in datasource which implements IDisplayNameProvider thread.
Having investigated all the information, we came to the conclusion that the problem with expressions with the aggregate operator doesn't directly relate to the current issue.
If a field is serialized incorrectly in the 13.2.5 version, it is converted correctly by a hotfix. If a field isn't converted to the display name at all, it is serialized correctly.
So we have decided to create a separate ticket: End-User Designer - Display names are handled incorrectly in an expression with the aggregate operator
Please refer to it for further correspondence on this item.
However you see fit to organize the fixes is fine, as long as we eventually have a product that works end to end. Thanks!