There's been a few threads regarding selecting a report writer, so here's some info on my latest experiences with Visual Studio (rdlc) reports.
I think I'm officially abandoning them and going back to the DevExpres Xtra Reports. (Even though the Xtra Reports has its limitations, they are more in the area of developer efficiency than in how it works.)
First off, I think the rdlc designer/viewer was a great idea and version 2 may be be a very good tool - which is to say this is a classic version 1 Microsoft product, if ya know what I mean. I believe most of its limitations and issue have something to do with the fact that it is some kind of port of the SQL Reporting Services technology. While that is a great idea, that paradigm has some breakdowns in a windows forms environment.
There's the issue of DataSources. The SQL version of this technology includes the query definition... that is the data source is part of the report definition. In the rdlc version you supply it the data sources. Now, the VS developers tried to make it support the powerful BindingSource paradigm like in Windows Forms development, but it doesn't quite work. It turns out the report definition has its own data sources, which are linked but not the same thing as the BindingSource data sources used when it runs.
So you have an extra layer of abstraction there which introduces some synchronizazion issues as you'd expect. Not anything that doesn't work or works "wrong" per se, but there's some stuff you have to do manually that you don't think about in Forms design. One of the aspects of that is if you're designing a form you can have the BindingSource components all related to each other by pointing one's DataSource to a property of the data source of another. At runtime you only have to give the root BindingSource a "real" data object. Not so with reports - you have to explicitly give each BindingSource it's data source at runtime.
Secondly, I've experienced some oddities in the rendering. Basically there are fairly drastic inconsistencies between the way the report looks in the designer, the viewer in "normal" mode, the viewer in print layout mode, and when actually printed.
One of them is that in some cases the left edges of text is "clipped" in the viewer. It looks as if the containing textbox is crowding in on the actual text and covering the left edge of the first character. For certain characters it is rather difficult to discern what it's supposed to be. Everything looks perfectly fine when printing though.
The more drastic problem is with textboxes with borders. Everything looks fine in the viewer if in print layout view and when printed. But in the normal/default viewing mode the text inside the textbox is in two rows such that nothing is really readable. I don't have the textbox set to AutoGrow since that would interfere with the graphical aspect of the layout.
You have to imagine this scene - I design the report and everything looks perfect. I run the app and call up the report and the layout is wacked. I switch to print layout mode in the viewer and the layout looks right but there's still that clipping. I print the thing and it looks perfect as in the designer. Is it just me or is that utterly ridiculous?
If I'm understanding the newsgroup response correctly, this is due to the fact that the default view mode is actually a pure HTML translation and rendering. One of the suggestions was not to use freeform placement but keep everything in tables since that works better in HTML. Ugh! I think it's pure nonsense to have a windows form report writer that's constrained by having to work in the paradigm of HTML tables.
So, I'm very close to making the decision to going back to Xtra Reports as the report writer standard here. I know I can't live with these rdlc rendering/viewing limitations.
DansDreams:
First off, I think the rdlc designer/viewer was a great idea and version 2 may be be a very good tool - which is to say this is a classic version 1 Microsoft product, if ya know what I mean. I believe most of its limitations and issue have something to do with the fact that it is some kind of port of the SQL Reporting Services technology. While that is a great idea, that paradigm has some breakdowns in a windows forms environment.
There's the issue of DataSources. The SQL version of this technology includes the query definition... that is the data source is part of the report definition. In the rdlc version you supply it the data sources. Now, the VS developers tried to make it support the powerful BindingSource paradigm like in Windows Forms development, but it doesn't quite work. It turns out the report definition has its own data sources, which are linked but not the same thing as the BindingSource data sources used when it runs.
So you have an extra layer of abstraction there which introduces some synchronizazion issues as you'd expect. Not anything that doesn't work or works "wrong" per se, but there's some stuff you have to do manually that you don't think about in Forms design. One of the aspects of that is if you're designing a form you can have the BindingSource components all related to each other by pointing one's DataSource to a property of the data source of another. At runtime you only have to give the root BindingSource a "real" data object. Not so with reports - you have to explicitly give each BindingSource it's data source at runtime.
ajj3085:
I haven't gotten as much into it as you have, but to me it seemed the only real difference is that rdlc files don't include sql data source, so its not so much of a port as it is 99% the same, except a client report gets its data through code while a server report knows how to talk to Sql server. Changing from client to server seems to be just a matter of changing the file extension and adding or removing a small section of xml.
Maybe "port" wasn't the right word. Those differences that seem subtle I believe are quite significant. There's no concept of print layout mode in the server version, for example. So, rather than having a report writer tool that is very robust in the windows forms arena like countless other products, you have this rather shoddy wrapper thrown what is basically a browser.
The way I've been working with it, I setup bindingsource objects just as if I was doing so for a form, then I take those binding source objects and hand them to the report through its data source object model. I'm not sure how it would work otherwise; unlike a windows Form, there's no code behind for the designer to generate code in for a rdlc report, its just an xml file.
You are not using the standard viewer paradigm then? With rdlc reports there's an unusual relationship between the designer and the "viewer". The BindingSource components are on the viewer, and the viewer designer has a mechanism for synchronizing them with the true data sources of the report, so you define ClassA -> BindingSourceA -> ReportDataSourceA. That the additional effort I'm talking about. There's no corresponding thing on a windows form or in any of the report writers I've worked with.
Designing an Xtra Reports report is identical to designing a form. Throw on some BindingSource components, relate them to each other, and paint the report. Done. When I want to view it at runtime I set the root BindingSource's DataSource to the hydrated object. Done. Just like a form.
I've actually stopped doing this in windows forms, because when you need to rebind to a new object, you have to setup the 'child' bindingsource's datasource's anyway. At least that's what I found, because the children datasources weren't being pointed to the 'new' child objects. That is, they were still refering to the collection on the OLD business object.
That works fine for me. I only ever deal with the root BindingSource at runtime on a form. That's the beauty of the thing!
I guess if we could combine your working rdlc's with my working BindingSources we'd really have something. :)
Regarding your rending problems, when you have the report open in the designer? I get some warnings on on Error List about overlapping controls, but only if the report is in design mode. I personaly haven't had any rendering problems yet. It seems odd that the default view would be an html view, but it might make sense if its taking the rdlc as a stylesheet and your data as xml.
No, everything looks perfect in the designer and I have no hard Errors.
If you want you can try what I am. I have a rectangle with a border. On that border (overlapping) I place a textbox with its borders turned on. I'm going for something that looks kind of like the Forms group box... a box with a title. In this case I want the title to be in a bordered box itself. You have to make sure to move the textbox on "top" of the rectangle so it covers it.
Because I'm covering the rectangle border like this, obviously the size of the textbox relative to its text is pretty critical. If I make the textbox big enough to cover all the rendering scenarios it looks stupid in others because it contains a bunch of whitespace.
Maybe "port" wasn't the right word. Those differences that seem subtle I believe are quite significant. There's no concept of print layout mode in the server version, for example. So, rather than having a report writer tool that is very robust in the windows forms arena like countless other products, you have this rather shoddy wrapper thrown what is basically a browser.
You are not using the standard viewer paradigm then? With rdlc reports there's an unusual relationship between the designer and the "viewer". The BindingSource components are on the viewer, and the viewer designer has a mechanism for synchronizing them with the true data sources of the report, so you define ClassA -> BindingSourceA -> ReportDataSourceA. That the additional effort I'm talking about. There's no corresponding thing on a windows form or in any of the report writers I've worked with.
Designing an Xtra Reports report is identical to designing a form. Throw on some BindingSource components, relate them to each other, and paint the report. Done. When I want to view it at runtime I set the root BindingSource's DataSource to the hydrated object. Done. Just like a form.
No, everything looks perfect in the designer and I have no hard Errors.
Well, I'm not sure I could repo doing that.. but the rdlc is just xml, so if you could post some xml (including the xml for the data sources) I could try to see what you're looking at.If you want you can try what I am. I have a rectangle with a border. On that border (overlapping) I place a textbox with its borders turned on. I'm going for something that looks kind of like the Forms group box... a box with a title. In this case I want the title to be in a bordered box itself. You have to make sure to move the textbox on "top" of the rectangle so it covers it.Because I'm covering the rectangle border like this, obviously the size of the textbox relative to its text is pretty critical. If I make the textbox big enough to cover all the rendering scenarios it looks stupid in others because it contains a bunch of whitespace.
So if you use the Windows ReportViewer control for a server report, the control no longer offers a print layout mode? Or are you browsering to the ReportServer web on the Sql Server?
That's my understanding - with SQL RS it's straight browsing HTML. I'm not using it so somebody else can jump in if that's wrong.
Not sure what the 'standard viewer paradigm' would be. I have the ReportViewer control on a form. I set the viewer to the report I want, and the BindingSource controls are on this form.
Right. But those BindingSource components are different than the data sources in the report definition. There's an extra layer there not present in the Windows Forms paradigm, or Xtra Reports for that matter. It's not a tremendously huge issue, but it's there and it's significant IMO.
That does sound easier.. but its not much code, and almost all of the code I posted was generated.. I just moved it so the form could handle any report. (On a side note, I think this is a good place for the strategy pattern).
Yes, but my point is that it's code that doesn't follow the very powerful yet simple model of forms. It's powerful but not so simple, and I think that's because of trying to squeeze the round rdl paradigm into the square smart client one.
Well, I'm not sure I could repo doing that.. but the rdlc is just xml, so if you could post some xml (including the xml for the data sources) I could try to see what you're looking at.
That's a LOT of xml dude. Way too much to put in a message here. It's not that hard to do from my description, just a rectangle with borders on and a textbox with borders on placed overlapping the rectangle's borders. Make the textbox just long enough to display its text in the designer.
BTW, I do have the viewer going straight to print layout mode to somewhat avoid this problem, but I missed removing the button. Good idea if I proceed with using this tool.
That's my understanding - with SQL RS it's straight browsing HTML. I'm not using it so somebody else can jump in if that's wrong.
Right. But those BindingSource components are different than the data sources in the report definition. There's an extra layer there not present in the Windows Forms paradigm, or Xtra Reports for that matter. It's not a tremendously huge issue, but it's there and it's significant IMO.
Well, I guess here we'll disagree. I personally don't think the extra few lines are a big deal.
Yes, but my point is that it's code that doesn't follow the very powerful yet simple model of forms. It's powerful but not so simple, and I think that's because of trying to squeeze the round rdl paradigm into the square smart client one.
Again, I think this is just a point we disagree on. There's code we have to generate ourselves in the forms world to (setting the bindingsources data source), so a few more lines I don't think matters... but now we're talking about personal preferences.
That's a LOT of xml dude. Way too much to put in a message here. It's not that hard to do from my description, just a rectangle with borders on and a textbox with borders on placed overlapping the rectangle's borders. Make the textbox just long enough to display its text in the designer.
Too much to fit in a zip file? ![Smile [:)]](/emoticons/emotion-1.gif)
I'll give your instructions a try when I get a chance in my off hours.
BTW, I do have the viewer going straight to print layout mode to somewhat avoid this problem, but I missed removing the button. Good idea if I proceed with using this tool.
There is a problem which I solved by setting set the inital layout, but for the life of me I can't remember what it was.
Not sure what you mean by removing the button...?Well, I guess here we'll disagree. I personally don't think the extra few lines are a big deal.
Again, I think this is just a point we disagree on. There's code we have to generate ourselves in the forms world to (setting the bindingsources data source), so a few more lines I don't think matters... but now we're talking about personal preferences.
To be clear (and not just to argue), I'm talking about the extra understanding you must have and the somewhat obscure method by which you keep the report datasources synchronized with the viewer BindingSource components when the source business object changes. It is indeed just a few rather simple steps once you understand them, but they're not things you ever worry about in forms or Xtra Report design. I would rather bet that if MS were actually designing a report writer from scratch and not leveraging the rdl technology this wouldn't be the case, since it isn't in other products. (I won't digress into the discussion of SQL RS as just a big hook to lock you into SQL Server.)
Too much to fit in a zip file?
I thought attachments were a no-no. How do you even attach a file?
We started using the Report Viewer control in our CSLA app after looking around and having been a ActiveReports user for our previous com based app.
I actually like it quite a bit mainly because it is somewhat of a standard language and being XML based you can do just about anything by generating your own RDL in code and doing a LoadReportDefinition() on it. Although you really can't go completely unbound as it complains if there is no data source at all so I just dummy databind my business object without actually binding any report elements to it.
I know what you mean about the datasources being somewhat over complicated, although if you look at the RDL specs you can tell they where shooting for abstracting the datasources away from any underlying technology, yet at the same time they stick to a relational table/column/row for the actual RDL datasource.
As far as the view mode issues, I get some border clipping based on the controls window resolution as it doesnt seem to do any kind of multisample/AA on the content like say a acrobat viewer does on PDF's.
One thing you can do is ReportViewer1.SetDisplayMode(Microsoft.Reporting.WinForms.DisplayMode.PrintLayout); and I believe you can remove the print layout button from the toolbar as well if you don't want them switching to interactive mode.
Overall I think RDL has a lot of potential mainly since MS is trying to standarize it and you can already see thrid parties trying to implement it. See http://www.fyireporting.com/ for a GPL implemention viewer and renderer and even a GUI end user desginer.
Justin
Copyright (c) Marimer LLC