Incorrect culture used in binding

[Sparky]

Hi,

I have a teport, designed with standalone report designer with a text box in it, with binding on Style.BorderWidth.Bottom = Format("{0:0.0}pt",Fields.BottomBorderWidth)

Fields.BottomBorderWidth's type is double.

After upgrading to latest version, this stopped working when partial values are used for Fields.BottomBorderWidth.

For example, on the previous version if Fields.BottomBorderWidth's value was 0.5, this resulted in correct 0.5pt border, but in the last version it results in 5pt border.

The culture of my computer is "bg-BG", and this behavior depends on it on the latest version end does not depend on it in the previous version. It doesn't matter what culture I select for the report or for the textbox - the format function always uses the system setting, but the renderer always uses either invariant culture or "en-US" when trying to read the binding value and apply it to the style of the text box. So, when I set my system's culture to "en-US", everything is OK in both versions, and when I set my system's culture to "bg-BG", this only works in R2 2016, but not in the latest version.

[Stef]

Hi Spartak,

Please check the Changes section of the R3 2016 release:
"..Expressions

Binding expressions with static value for Size and Location properties now use InvariantCulture list separator - comma (,). For example: ="2cm, 1cm"  ..."

Then check what is the string produced by the expression and if depending on the culture, the string is built with a ',' as decimal separator. note that you use an expression, and it will be evaluated in the context of the current thread's culture of the application (as localization).

On a side note, my recommendation is to use whole values as internal algorithms may round the passed value, also on displaying the report different media may have different interpretation of the value for the border. Pixels may be more suitable as units.

Regards,
Stef
Telerik by Progress

[Sparky]

OK. I see. But how do you expect someone to use binding for Width and all other possible non-whole number properties, dates and all other possible culture dependant properties? Both Format and CStr are using system thread culture, and  the binder uses invariant culture. This also means that the report will run differently on systems with different locale, and this also presents a problem when multi-language reports are running on the same system. I am currently setting the thread culture the same as the report culture, and this partially solves some problems, but still the binder problem cannot be solved this way.

I think you should provide a way to select the culture for Format and other data converting functions, otherwise this change will be a huge limitation for binding.

I'll stay with R2 for now, as this is unacceptable. Using pixels in this exact case is also unacceptable, because it is device dependant. I need half point or 0.2mm width of border and there's no way to do it with whole numbers, unless you provide convenient unit for this, for example mils or micrometers.

 

[Stef]

Hi Spartak,

You are right about the culture settings. Our development team will improve the Format text function to accept culture or to use the Culture of the item. For the time being, I can suggest you to use a user function where you can control the formatting in code.

Your Telerik points are updated to thank you for bringing the issue to our attention.


About pixels,correct, it is a device oriented format that may not be suitable if you use printers with high resolution and you need to match a standard document template.

Regards,
Stef
Telerik by Progress

[Sparky]

Culture parameter for format function or some other type of culture selection for binding is a solution, but using the culture of the element is not, since the binder always uses invariant.

I cannot use user functions in the standart way, because I don't have classes for each report. I am using standalone report designer and the only rendering the result, adding report data sources and parameters programmatically.

Also you can consider  implementing a way to add "object" report parameters programmaticaly in order to call object parameter's methods and use it's fields and properties. This will also give a great flexibility and straightforward way to do much more things much more easily, when using standalone report designer like I do.

[Stef]

Hello Spartak,

Thank you for this feedback.


By culture I mean the Culture property. For more details check Culture Inheritance.
The improvement is yet in discussion and the conversion of values with invariant culture will be considered with localization, globalization and types of fields.


About using user functions in the Standalone Report Designer, they can be built in an external DLL that extends the designer - Extending Report Designer (step by step tutorials are linked at the bottom of the help article).


About having a support for Object by report parameters, please feel free to log a feature request, including details about the use cases.
As a workaround, you can use ReportItem.DataObject in expressions - How to use the ReportItem.DataObject property in expressions. Let assume you have a data model with properties of custom type, that is used as data source of the report. These properties will become fields in the report, and you can use them to filter data of data sources of nested data items - Use parent Data item's data for child Data item's DataSource parameter.

Regards,
Stef
Telerik by Progress