While report viewer correctly identifies any DateTime field data type and applies proper formatting. The ExportToExcell operation yield the the same field as double (or float).
The work around is to force Telerik.Reporting.TextBox.Format to "{0:G}".
I have published the test project here: http://dl.dropbox.com/u/2192462/Telerick.Reporting.Bug/WpfApplication1.7z
Cheers,
4 Answers, 1 is accepted
The described behavior is by design. As noted in the Design Considerations for Excel Rendering help article, if a valid format string is detected by the rendering extension, the raw value will be stored in the cell as a Number and an Excel Number Format will be applied. Otherwise the value will just be stored in the cell, again as a Number, but without formatting. Even unformatted, it would be possible to use the resulting cell in Excel functions.
Best wishes,Peter
the Telerik team
I thought it might be the case. Thus it is not a bug but a design flaw. Minor, but a flaw. I think you may consider changing it in the future releases.
The fundamental concept of all (except Excel) exporting algorithms is "what you see in the report is what you get in the exported output". The ExportToExcel routine clearly does not implement this concept while other exports do.
At the same time the paradigm you described (no formatting info -> render raw value) is not followed by the ReportViewer control. This control is smart enough to understand that the default formatting for DateTime type is "{0:G}". So why ExportToExcel cannot do the same.
I see the actual problem not in the decision to handle or not to handle default formatting by one or another routine but in the inconsistency in making such decisions across all data rendering/transformation routines.
I am not picky I just want to improve the product, which I in fact found to be very solid and mature.
All the best,
Taras
We have discussed the current reporting behavior regarding the DateTime format in the Excel Rendering Extension and concluded that your suggestion makes sense. Thus we will add a default format for the DateTime types for example {0:G}. Still this is a low priority task so I can't engage with a time frame when the suggested improvement will be available.
Your Telerik points have been updated for bringing this to our attention.
Peter
the Telerik team
And I think "low priority" is quite appropriate in this case. Particularly because the adequate work around is available.
Best regards,
Taras