I've created a few reporting services local (Visual Studio) reports to see
if this is a viable enterprise reporting option. I'm having rather abysmal
experience with the report viewer.
I design my report in the designer and it looks great. I run the
application and view it on the screen and see
- The left edges of text in text boxes is "clipped", as if the text is
running outside the textbox margin or something
- Some textboxes have switched to multiline as if it isn't long enough to
display the contents, but the textbox isn't tall enough for that and what
displays is just gobbledy-gook.
If I switch the view to print layout mode the clipping is still there but
the textboxes now display the entire contents horizontally like they did in
the designer.
In any case, if I print the report from the viewer it comes out pretty much
like it looked in the designer.
So, to recap:
- Left edges of text boxes are clipped in the viewer
- Reports layout like I designed them when in print layout mode but not
otherwise
- Printed reports don't look like they do when viewed on the screen
I must be doing something horribly wrong or have a misunderstanding of the
paradigm, because in my mind this is ridiculous for a reporting tool to
behave this way. I understand the CanGrow property, but it only controls
vertical sizing and in order to preserve my report esthetics I would need it
to grow horizontally.Make sure you report items (Textboxes, Lines, Rectangles, etc) do not
overlap. This usually causes the report to behave oddly in HTML as it
cannot overlap html objects very well. Usually you can avoid
overlapping items by using a table for your data region, instead of the
freeform List. Also, check the padding of your textboxes, and increase
the padding if needed.
Textboxes do not grow horizontally as this is the layout of the report
and is the behavior by design. You should increase the width of your
textboxes to the max size that you can within your report layout for
the data that will be displayed in them. You can set the CanGrow
property to true, which basically allows the renderer to wrap the text
to another line(s), like you said, controlling vertical sizing.
A lot of times, the result you get from viewing the report in the
viewer in HTML will not be exactly the same as when printing or
exporting to PDF or TIFF. The latter are print layout formats, and
will render the reports slightly different, because their media is
paper. For example, if you report has a page footer, in HTML, the
footer will show immediately after last item on the page, even if the
item is in the "middle" of the page, because HTML does not have concept
of "page sizes". If you print it or export to PDF, you will notice
that the renderer places the page footer at the bottom of the paper
page.
Hope this helps you!
Regards,
Thiago Silva, MCAD.NET
On Nov 22, 7:22 am, "Daniel Billingsley"
<DanielBillings...@.newsgroup.nospam> wrote:
> I've created a few reporting services local (Visual Studio) reports to see
> if this is a viable enterprise reporting option. I'm having rather abysmal
> experience with the report viewer.
> I design my report in the designer and it looks great. I run the
> application and view it on the screen and see
> - The left edges of text in text boxes is "clipped", as if the text is
> running outside the textbox margin or something
> - Some textboxes have switched to multiline as if it isn't long enough to
> display the contents, but the textbox isn't tall enough for that and what
> displays is just gobbledy-gook.
> If I switch the view to print layout mode the clipping is still there but
> the textboxes now display the entire contents horizontally like they did in
> the designer.
> In any case, if I print the report from the viewer it comes out pretty much
> like it looked in the designer.
> So, to recap:
> - Left edges of text boxes are clipped in the viewer
> - Reports layout like I designed them when in print layout mode but not
> otherwise
> - Printed reports don't look like they do when viewed on the screen
> I must be doing something horribly wrong or have a misunderstanding of the
> paradigm, because in my mind this is ridiculous for a reporting tool to
> behave this way. I understand the CanGrow property, but it only controls
> vertical sizing and in order to preserve my report esthetics I would need it
> to grow horizontally.|||Well, I have to say I think not handling overlapping items is a ridiculous
limitation - one that surely has the graphics designers in the crowd
laughing their rears off. My use of it is not a list layout issue, it's a
graphic design issue, so using a table doesn't help. What I'm trying to
create is an effect similar to the windows forms GroupBox whereby there's a
box with a border that is interrupted for the "title" of the box.
Additionally, I'd like the title to be surrounded with a border itself.
This is not really all that complex graphically, so I think it's a rather
sever limitation that the rdlc report can't handle it.
Considering that increasing the width of the textbox doesn't really work.
The problem I'm trying to point out is that I can't predict what it will
look like at runtime while in the designer. And even if I put forth the
painful effort of making a change and then having to run the application to
see the results (another completely ridiculous limitation), the problem
still exists that it would look good in the view but when printed look like
I was an idiot because there'd be a bunch of whitespace in the end of the
box (border).
IMPORTANT NOTE - this is all really a problem with textboxes with borders in
general and really doesn't have anything to do with the fact that I am using
it in an overlapping way in this particular case.
I say again, for a report writer not to be able to predict the results, and
for the results to be that different between viewing and printing, is
unacceptable. Period. Yes, I would expect the differences in the way page
footers are handled because there are no "pages" in HTML. Of course it
would work that way. But not that the actual layout of the body of the
report would change so significantly.
I did not appreciate that the default for the viewer was an HTML view. This
seems like another case where the relationship to the SQL RS engine is a
liability.
"tafs7" <tsilva7@.gmail.com> wrote in message
news:1164347626.531755.16330@.l39g2000cwd.googlegroups.com...
> Make sure you report items (Textboxes, Lines, Rectangles, etc) do not
> overlap. This usually causes the report to behave oddly in HTML as it
> cannot overlap html objects very well. Usually you can avoid
> overlapping items by using a table for your data region, instead of the
> freeform List. Also, check the padding of your textboxes, and increase
> the padding if needed.
> Textboxes do not grow horizontally as this is the layout of the report
> and is the behavior by design. You should increase the width of your
> textboxes to the max size that you can within your report layout for
> the data that will be displayed in them. You can set the CanGrow
> property to true, which basically allows the renderer to wrap the text
> to another line(s), like you said, controlling vertical sizing.
> A lot of times, the result you get from viewing the report in the
> viewer in HTML will not be exactly the same as when printing or
> exporting to PDF or TIFF. The latter are print layout formats, and
> will render the reports slightly different, because their media is
> paper. For example, if you report has a page footer, in HTML, the
> footer will show immediately after last item on the page, even if the
> item is in the "middle" of the page, because HTML does not have concept
> of "page sizes". If you print it or export to PDF, you will notice
> that the renderer places the page footer at the bottom of the paper
> page.
> Hope this helps you!
> Regards,
> Thiago Silva, MCAD.NET
>
> On Nov 22, 7:22 am, "Daniel Billingsley"
> <DanielBillings...@.newsgroup.nospam> wrote:
>> I've created a few reporting services local (Visual Studio) reports to
>> see
>> if this is a viable enterprise reporting option. I'm having rather
>> abysmal
>> experience with the report viewer.
>> I design my report in the designer and it looks great. I run the
>> application and view it on the screen and see
>> - The left edges of text in text boxes is "clipped", as if the text is
>> running outside the textbox margin or something
>> - Some textboxes have switched to multiline as if it isn't long enough to
>> display the contents, but the textbox isn't tall enough for that and what
>> displays is just gobbledy-gook.
>> If I switch the view to print layout mode the clipping is still there but
>> the textboxes now display the entire contents horizontally like they did
>> in
>> the designer.
>> In any case, if I print the report from the viewer it comes out pretty
>> much
>> like it looked in the designer.
>> So, to recap:
>> - Left edges of text boxes are clipped in the viewer
>> - Reports layout like I designed them when in print layout mode but not
>> otherwise
>> - Printed reports don't look like they do when viewed on the screen
>> I must be doing something horribly wrong or have a misunderstanding of
>> the
>> paradigm, because in my mind this is ridiculous for a reporting tool to
>> behave this way. I understand the CanGrow property, but it only controls
>> vertical sizing and in order to preserve my report esthetics I would need
>> it
>> to grow horizontally.
>|||Hey, Daniel
Have you tried using a rectangle with borders, instead of a textbox as
the container? I don't think you'll get quite the same effect as the
GroupBox with the title, but at least your rectangle will serve as a
container for other items, and you can have a textbox on the inside of
this rectangle at the top left corner acting as the "title" (note the
"Parent" property in the property page of any textbox placed inside the
rectangle, and you should see the rectangle name)
There is really nothing that prevents you from overlapping items in a
report, however in this version of the product, it unfortunately
doesn't do well rendering overlaps in all renderers. This is mainly a
problem for the HTML rendering extension of the viewer. The same
report, when exported to PDF, will look perfect, though.
In the Visual Studio designer, when you preview a report that contains
overlapped items, you will get a warning in the output window but this
will not prevent you from running the report:
[rsOverlappingReportItems] The textbox 'textbox3' and the rectangle
'rectangle1' overlap. Overlapping report items are not supported in
all renderers.
Build complete -- 0 errors, 1 warnings
As far as the textbox stretching horizontally, it would make no sense
to allow for textboxes to do that because it could inherently stretch
the width of the report body and page width causing the report to print
extra pages just for the extra width, since the printed page size is a
property that is set in the report (e.g. 8.5x11in vs. 11x8.5in -
portrait or landscape letter).
Now, since you're using the RDLC format, I am assuming you have a
custom application that provides a UI to the user for selecting reports
and entering parameters (if required). If that's the case, then your
application is responsible for providing the data as well and then
handing that over to the ReportViewer control for rendering. As such,
there is no way to "preview" your report from the Visual Studio
designer, because it doesn't know where the data is coming from. I
would recommend developing your reports as regular RDL files to begin
with, so you can test on the VS designer. You can even preview it w/
the ReportViewer by right-clicking the report name in the Solution
Explorer and selecting "Run". This will spin off a separate process
with an external windows app hosting the ReportViewer (note that
because this is a windows app, it still won't render the actual HTML
results you'd get from Internet Explorer).
Once you're happy with the results, you can "doctor" your RDL file so
it becomes an RDLC (see http://www.gotreportviewer.com for more
details) that is usable by your custom application.
Hope this helps you.
If you need any references to help you further your skills in SSRS, I
would recommend reading some of the SSRS team blogs for tips:
All about the ReportViewer - http://www.gotreportviewer.com/
Brian Welcker - http://blogs.msdn.com/bwelcker
Chris Hays - http://blogs.msdn.com/ChrisHays/ <= Sleazy Hacks for SSRS
:)
Tudor's blog - http://blogs.msdn.com/tudortr/
Lukasz Pawlowski - http://blogs.msdn.com/lukaszp/
Bob Meyers- http://blogs.msdn.com/bobmeyers
Regards,
Thiago Silva, MCAD.NET
Daniel Billingsley wrote:
> Well, I have to say I think not handling overlapping items is a ridiculous
> limitation - one that surely has the graphics designers in the crowd
> laughing their rears off. My use of it is not a list layout issue, it's a
> graphic design issue, so using a table doesn't help. What I'm trying to
> create is an effect similar to the windows forms GroupBox whereby there's a
> box with a border that is interrupted for the "title" of the box.
> Additionally, I'd like the title to be surrounded with a border itself.
> This is not really all that complex graphically, so I think it's a rather
> sever limitation that the rdlc report can't handle it.
> Considering that increasing the width of the textbox doesn't really work.
> The problem I'm trying to point out is that I can't predict what it will
> look like at runtime while in the designer. And even if I put forth the
> painful effort of making a change and then having to run the application to
> see the results (another completely ridiculous limitation), the problem
> still exists that it would look good in the view but when printed look like
> I was an idiot because there'd be a bunch of whitespace in the end of the
> box (border).
> IMPORTANT NOTE - this is all really a problem with textboxes with borders in
> general and really doesn't have anything to do with the fact that I am using
> it in an overlapping way in this particular case.
> I say again, for a report writer not to be able to predict the results, and
> for the results to be that different between viewing and printing, is
> unacceptable. Period. Yes, I would expect the differences in the way page
> footers are handled because there are no "pages" in HTML. Of course it
> would work that way. But not that the actual layout of the body of the
> report would change so significantly.
> I did not appreciate that the default for the viewer was an HTML view. This
> seems like another case where the relationship to the SQL RS engine is a
> liability.
> "tafs7" <tsilva7@.gmail.com> wrote in message
> news:1164347626.531755.16330@.l39g2000cwd.googlegroups.com...
> >
> > Make sure you report items (Textboxes, Lines, Rectangles, etc) do not
> > overlap. This usually causes the report to behave oddly in HTML as it
> > cannot overlap html objects very well. Usually you can avoid
> > overlapping items by using a table for your data region, instead of the
> > freeform List. Also, check the padding of your textboxes, and increase
> > the padding if needed.
> >
> > Textboxes do not grow horizontally as this is the layout of the report
> > and is the behavior by design. You should increase the width of your
> > textboxes to the max size that you can within your report layout for
> > the data that will be displayed in them. You can set the CanGrow
> > property to true, which basically allows the renderer to wrap the text
> > to another line(s), like you said, controlling vertical sizing.
> >
> > A lot of times, the result you get from viewing the report in the
> > viewer in HTML will not be exactly the same as when printing or
> > exporting to PDF or TIFF. The latter are print layout formats, and
> > will render the reports slightly different, because their media is
> > paper. For example, if you report has a page footer, in HTML, the
> > footer will show immediately after last item on the page, even if the
> > item is in the "middle" of the page, because HTML does not have concept
> > of "page sizes". If you print it or export to PDF, you will notice
> > that the renderer places the page footer at the bottom of the paper
> > page.
> >
> > Hope this helps you!
> >
> > Regards,
> > Thiago Silva, MCAD.NET
> >
> >
> > On Nov 22, 7:22 am, "Daniel Billingsley"
> > <DanielBillings...@.newsgroup.nospam> wrote:
> >> I've created a few reporting services local (Visual Studio) reports to
> >> see
> >> if this is a viable enterprise reporting option. I'm having rather
> >> abysmal
> >> experience with the report viewer.
> >>
> >> I design my report in the designer and it looks great. I run the
> >> application and view it on the screen and see
> >> - The left edges of text in text boxes is "clipped", as if the text is
> >> running outside the textbox margin or something
> >> - Some textboxes have switched to multiline as if it isn't long enough to
> >> display the contents, but the textbox isn't tall enough for that and what
> >> displays is just gobbledy-gook.
> >>
> >> If I switch the view to print layout mode the clipping is still there but
> >> the textboxes now display the entire contents horizontally like they did
> >> in
> >> the designer.
> >>
> >> In any case, if I print the report from the viewer it comes out pretty
> >> much
> >> like it looked in the designer.
> >>
> >> So, to recap:
> >> - Left edges of text boxes are clipped in the viewer
> >> - Reports layout like I designed them when in print layout mode but not
> >> otherwise
> >> - Printed reports don't look like they do when viewed on the screen
> >>
> >> I must be doing something horribly wrong or have a misunderstanding of
> >> the
> >> paradigm, because in my mind this is ridiculous for a reporting tool to
> >> behave this way. I understand the CanGrow property, but it only controls
> >> vertical sizing and in order to preserve my report esthetics I would need
> >> it
> >> to grow horizontally.
> >
|||I am also facing the same problem, infact i copied the dll file into wwwroot directory but still getting the same error 'in correct or unsupported HTTP function call was made'.