I'm using the report viewer control included in Visual Studio 2005 and something odd is happening; when I set the margins on the report and I run the application the report viewer adds a page break after each content page, so if I have 2 content pages I end up having 4 pages of which 2 of them are blank pages.
If I set the margins of the report as zero then the report displays ok but of course it doesn't look good without the margins (and won't print properly)
I'm pretty sure the content is not wrapping or something that could cause this since I intentionally designed the tables to fit in 6 inches so, 6 inches plus 2 (one for each side margin) are 8 and I still have half an inch of space there so things don't mess up since this is in letter size which is 8.5" x 11"
Anybody has had this same behavior?
Thanks in advance.
Found the solution, turns out that the body should not be wider than the report size so for example if you have a standard letter page: 8.5" x 11" than the body should be less than 8.5, pay special attention if you have margins since you have to subtract those inches too, I want a one inch margin per side so left and right would sum up two inches:
8.5 - 2 = 6.5
So if you plan to have a letter report with one inch margins make sure the body is 6.5 at the most then it would fit.
Pretty obvious huh? but I did not figured it out at the beginning since the report viewer designer does not have any rulers to mark the beginning of the body, only for the report.
Related
I have a SSRS RDL that is formated to fit on a three column lable sheet. When exported to PDF the 2nd column is not populated and on the next page the 2nd column is the only column populated. This continues to happen for as much data as I have. Has anyone had any problems with this or might have an idea on where the problem might be?
These kinds of quirks are usually related to the margins. Make sure that the actual label area does not exceed the page size, accounting for the margins. Also, printer drivers can cause a similar issue because of content-to-page-size issues, where the report shows correct on-screen but when printing, shifts content to a new page.
This is because of page setup properties. For example if a page is set to letter size(8.5in X 11in) and left and right margins to 1 inch. then you have adjust you report body size to 6.5 inch or below, if it exceeds above 6.5 inch, then leads to split data to other pages when exported to PDF.
I have a RDLC report.
The page is 21cm wide with 1cm margins on both sides (which leaves us 19cm for contents).
The body of the report is 18.96cm wide
There is a line element inside the report with Location = (0cm; 0cm) and EndPoint = (18.95cm, 0cm) thus the length is 18.95cm. This is like a horizontal separator line inside the report.
So, as you see the body should be enough to contain the line (19cm > 18.96cm > 18.95cm). But when I go and display the report in the ReportViewer/PrintLayout control the line actually generates an additional page (because it grows wider for some reason). And this shows up on the actual printed document (if you print it out).
Just in case - the simple view in ReportViewer and the exported report both look fine, no additional pages present.
Please tell me - how does this happen and if there are any workarounds to get a good PrintLayout view inside the ReportViewer control? I do not care about the PrintLayout view itself, but I care about printing the document out, which uses the same PrintLayout.
Yours is a strange scenario. Try giving a tolerance of 5mm (0.5cm) instead and let's see what happens.
In other words set the following
Body: 18.5cm
Line: Location = (0.25cm; 0cm) and End Point = (18.0cm; 0cm)
If that doesn't work, it probably means your page is taller than the size of paper you desire to print on.
A4 is 21cm x 29.7cm so make sure the height of your body is less than 29.7cm. If you have top and bottom margins, you'll have to subtract their values as well so the maximum height will be given as follows:
Max Height = 29.7 - (Top Margin Height + Bottom Margin Height + tolerance)
tolerance value should be approximately 0.5cm
I have a SSRS 2005 report form that is printing to a Zebra ZDesigner TLP 2844-Z label printer. The Interactive and Page sizes are set to 4" wide by 3" high. Since there is no paper orientation in SSRS, it is assuming this to be a landscape report when it should be a portrait thereby printing the labels sideways.
The users are able to export to a PDF and print after adjusting the print settings, but the extra clicks to produce/print the pdf's are unacceptable.
Is there a way to force the print job to print portrait or another workaround/trick to do this?
Can you just set your Page width to be 3" and your height to 4" ? (Not your Interactive Size, your Page Size)
How are you designing the report? There should be a property to modify for paper orientation in the report's properties...
From MSDN
So what defines a portrait vs. landscape report? If the PageHeight is less than the PageWidth, then it is landscape, otherwise it is portrait. It is important to understand that Reporting Services has no notion of the rotation of the paper in the printer. It is up to the applications that consume the output (Acrobat reader, print control) to determine the correct printer settings to best render the specified page size.
Note that the DeviceInfo settings can be used at report rendering time to override the page sizes in the definition. This is how the client print control works when you change margins or page size. In SP2 and SQL 2005 Reporting Services, the default page sizes are extracted from the definition at publish time and written to the ReportServer database as custom properties on the report. While you can programmatically change these via the SetProperties method on the web service, they will be overwritten if the report is republished (unlike parameter and datasource information).
I have a similar printer with a similar problem. Change the report orientation to portrait (the numbers will be backward). Then when you run the report click page setup. Change the size from "USER" to either "custom" or "template" (depending upon your printer). You should then be able to use your printer properties to change the size of the labels.
To prevent the SSRS WinForms ReportViewer from rotating your printed labels, use a square page. If the length and width are the same, ReportViewer will not rotate. I found that when I expanded the page size for my 2.5" x 1" label to 2.5" x 2.5", the print was oriented correctly on the stock and there was no waste. Perhaps Zebra's driver clips the blank area.
I also tried designing a rotated label using Text Box's WritingMode = Rotate270. That didn't help.
So I've recently had to create a report that emulates a Canadian customs form. The problem is that the report is printed on 11" x 14" paper, but uses a metric layout. As my FoxPro installation is on a machine with US-English units-of-measure, FoxPro tries to oblige by using an English ruler, and doing snap-to-grid on inch-based measurements. This creates some minor design issues obviously.
I understand that the reports are really just tables in disguise, and I have figured out how to turn on the Metric ruler (instead of the English one) by changing a record, and that is working as intended. However, the snap-to-grid functionality appears to want to snap on 48 units-to-an-inch, instead of something Metric. So moving a box around using a mouse results in the box being offset (again) in English measurements.
To get around this, I have taken to openning up the report as a table and manually converted all Metric units with a spreadsheet, and entered the offsets and sizes by hand. While this has worked well and appears to be very accurate, it's still error-prone.
So the question is, how do I get FoxPro 8 to snap-to-grid in Metric units on the report, so that I don't have to keep re-entering numbers by hand? It would be nice to get FoxPro to accomodate Metric in a fashion where I can align objects in the report using a mouse, rather than punching them in as numbers and "flipping" the report into design view to check it.
For reference, currently there are the following translations:
25.4 mm = 1 inch = 10,000 report units = 48 grid snap points
Obviously I'd like something closer to this:
25.4 mm = 1 inch = 10,000 report units = 25.4 grid snap points
Note: Yes, I have considered setting up a Virutal Machine with FoxPro that uses a Metric install, i.e. a Windows XP install set up for Canada. However, that will take another day or so to get the installation done, along with the rest of the development environment, so I'm trying to avoid that.
Hidden unless you've been exposed to more of it...
Modify your report.
Right-click, get to properties of the report.
On the tab for Ruler / Grid, there is a combobox which is defaulted to ruler of "inches", but you can change it to Metric/cm or Pixels. Below that is your grid snap and you can change the default of how many pixels to snap to.
Additionally, if you use your cursor keys, you can move the controls one pixel at a time for more precise alignments as needed. And if you need to resize a control's width, if you hold the Ctrl key down and use the arrow keys left/right, will shrink / strecth one pixel at a time instead of moving the control. Likewise for the moving and sizing if you pick multiple controls, they will ALL move or resize respectively.
HTH
Just spoke with a freind lastnight who has VFP8 installed. Based on that version, there MIGHT be a way to get metric for your reports. There is a setting on the reports from showing based on PIXELS, or SYSTEM METRIC. If you system configuration is based on inches, so too is the report. If you change your system metric to that of centimeters (or whatever equivalent it would be), so too should the report respect in design time.
HTH
I have text objects on a Crystal Report in Visual Studio with an initial capital. When I print the report, the text is all lower case.
And the reason is?
We have found a workaround for this problem. Not sure how this works :) - can any expert explain?
We found that this problem of case change was happening whenever the extent of text within any page / section of the report was going beyond the settings of the page size minus gutter, left/right margins, top/bottom margins set for the report.
As a workaround, we have asked all our reports developers to keep the text (for A4 size reports) to within 7.5 inches X 7.5 inches. The problem does not happen when this is adhered to.
Would definitely like to know exact reasons for the misbehavior though.
This might be affecting by some of the settings.
But if you go and edit the field , you can see it automatically change to lowercase.
If you agains change it back your case, then it will work fine.
It looks like it happend for one time. To be honest, I don't know why this happend