Crystal Reports for VS2010 Renders Differently than Crystal Reports

[Former Member]

I'm using Crystal Reports for VS2010 SP1 in an application I developed. The customer is editing the reports with the full version Crystal Reports (both XI R2 and 2011).

What we've found is that fields are rendering slightly differently in V2010 than in the full version designer, so that some fields that display correctly when the customer edits them are truncated in the viewer. There will be numeric fields that display correctly in the full version, but will display '#####' in the VS2010 viewer.

My customer is rather annoyed, because they cannot edit a report and be sure that it will display correctly in the application.

A previous version of the application using the runtime from Crystal Reports XI R2 developer edition didn't have this issue.

Is there any way do correct this or work around the issue?

[former_member11696 · Accepted solution]

Hi Scott,

Expand the field slightly, the # symbols are displayed because there is not enough room in the object to show the complete number value.

Don

[Former Member · Accepted solution]

Yes expanding the field width will remove the ####'s. The problem is when editing the report using the full version of Crystal the fields will be fine, but running the same report on the same machine using the VS2010 viewer, the fields will be cut-off.

So our customer is editing reports which look correct when they preview them in the Crystal Reports full edition editor, but when they view the same report in our application the fields are overflowing. The customer is annoyed because while editing the reports, they cannot tell if the report will work or not. They have to editing, import it into our application, and then test it.

This wasn't an issue when our application used the Crystal XI R2 SDK.

[former_member11696 · Accepted solution]

Hi Scott,

One reason is the older versions introduced a .5 font reduction in the viewers. This was a good thing for some but bad thing for others so I assume what the developers have done is leave the font as is and show those # symbols now to indicate the viewer you are using and font you are using works differently on the OS and the various viewers being used.

In CR designer it uses the GDI+ to render the data through classic C++ function calls. I .NET it too uses GDI+ but it's the Framework making the calls and the Framework handles screen mapping differently. We've had this issue/functionality limitations since version 9. Various reasons and various work arounds resulted in various outputs.

Another reason is the C++ viewer built into the Report Designer and the .NET framework handling the fonts work slightly differently when rendering. This has been tracked and few times here by me and in both cases the cause is GDI+ has bugs in it so it's nothing we can do. Post or log your issue with Microsoft, they may be able to fix it. Once they do then if it's still a problem in CR we can fix it depending on what MS does.

Another work around may be to use a fixed font like Courier or some other font that has a specified character area all characters use, it may make the characters space oddly but as for displaying it's always the same size.

All I can suggest is they get into a practice of testing their reports in your app before "publishing"

Thanks again

Don

[Former Member · Accepted solution]

Thanks Don, that's what I was afraid of, but thank you for the detailed response.