I've got a MS Access form that contains a subreport.
This is to allow a sort of dynamic preview of what you are going to get when you launch the print (in fact it's a form that allows to chose among different print layouts).
Let's say that my report is this:
It has also non-fixed fields, but it's not relevant for this issue.
The report is quite small and when presented in the form I would like to apply some sort of zoom, which actually I can't find.
Even if the subform/subreport control is much larger than the report, there seems not to exist a property that allows you to resize the report.
The result is this:
I tried setting Default View to Print Preview, no changes in visualization.
I hoped that switching to Print Preview would allow a greater control of the zoom (like actually happens when you launch a 'standard' print preview).
I tried setting FitToPage to true.
I tried to set AllowReportView to force the Print Preview, with no luck. At this point i think Print Preview is simply not allowed in a report inside a form.
Is there some (or some other) way to address this smallness problem?
Thanks in advance
P.S. If zooming is not possible, I would at least highlight the real report area because showing only the borders of the subform/subreport control would be confusing in this case.
Correct, report on form can only be displayed in ReportView. I don't think you can get 'zoom' feature by any method. As for 'highlight' of report area, code could set Backcolor property of each report section when report loads, like:
Private Sub Report_Load()
With Me
If .CurrentView = 6 Then
.ReportHeader.BackColor = vbYellow
.ReportFooter.BackColor = vbYellow
.PageHeaderSection.BackColor = vbYellow
.PageFooterSection.BackColor = vbYellow
.GroupHeader0.BackColor = vbYellow
.GroupFooter1.BackColor = vbYellow
.Detail.BackColor = vbYellow
End If
End With
End Sub
Might want to set all controls with transparent BackStyle.
Or instead of setting Backcolor, use a background image (watermark) on report.
I have the following (simplified) VBA code that demonstrates the problem while resizing a report and its controls from a module. To reproduce, create a new blank database, add a table and a report, then add this code into a new module:
Public Sub ResizeReport()
Dim rr as Report
Dim cc as Control
Set rr = Screen.ActiveReport
For Each cc in rr.Controls
cc.Width = 1 * 1440
Next
rr.Width = 5 * 1440
End Sub
If I open a report in Design View and run the macro, the changes stay when I change to other views (such as Report View, Layout View, or Print Preview). However, if I open the report in Layout View and run the macro, the report and its controls are resized, but as soon as I change the view mode, the report reverts to its state before the resize.
Please note that this issue does not occur if I manually resize the report/controls using drag handles or the Property Sheet while in Layout View.
Is there a command I need to issue after resizing the report/controls from VBA while in Layout View to get the changes to stick? Or should I be resizing the report/controls using different VBA commands?
I am using MS Access 2010.
Thank you for the short yet detailed question and functioning "MCVExample". I may need to refer other newbies to this question as an example of a perfect question. +1 for that even though the answer seems obvious. :)
You should save the report before changing it's view.
DoCmd.Save acReport, rr.Name
This will force the changes to "stick". The logic behind the report reverting to its previous state when changing view is to allow for dynamic, temporary changes at runtime, without permanently affecting the report.
More Information:
MSDN : DoCmd.Save Method (Access)
MSDN : Set Form, Report, and Control Properties in Code
We have a VB.NET program that is using Supergoo's ABCPDF version 6.1.1.2. Our program takes standard XML strings and places values in a corresponding PDF form field on the template PDF.
Problem:
We have over 3000 PDF files that have all been "tagged" with form fields. There could be up to 50 form fields on the template PDFs for a total of roughly 150,000 form fields in use potentially. We have noticed that some of these form fields have their form field common properties set to hidden by mistake. (see screenshot)
The issue is that the PDF coming back after the string values have been added are not showing up. Duh right? Fix the form field property and call it done. However, there is no way to know how many other of the other 150,000 form fields have been improperly tagged like this.
Does anyone know if I can adjust the PDF generation program to forcefully ignore that form field common property? Here is a sample of the vb.net code I am hoping to slightly alter...
Dim theDoc As Doc = New Doc
theDoc.Form.Fields("SampleFieldName").?????? 'can we set something here to ignore the hidden property?
According to the docs at
http://www.websupergoo.com/helppdfnet/source/6-abcpdf.objects/field/2-properties/page.htm
The .Page property of a Field object will tell you the page the field is on. Since Page is a class, if the result 'Is Nothing' then you know that the field is not visible since it doesn't appears on any page in the PDF document.
Please note that there are a few caveats when using fields that are not hidden but not actually visible when rendered (being too small, being spread on two pages, etc). If you need need to handle that you may be interested in http://www.websupergoo.com/helppdfnet/source/6-abcpdf.objects/field/2-properties/rect.htm depending on your use cases.
For the ABCPDF v6 software, I have discovered through Mihai's suggestion that it is possible. I have coded this C# example in the hopes that it helps someone down the road...
static void SetFillableFieldsToWriteableExample(string origFileLocation, string newFileLocation)
{
Doc theDoc = new Doc();
theDoc.Read(origFileLocation);
var theFields = theDoc.Form.GetFieldNames();
foreach (string theField in theFields)
{
Field theFieldInstance = theDoc.Form[theField];
theDoc.SetInfo(theFieldInstance.ID, "/F", "4");
}
theDoc.Save(newFileLocation);
}
I have tested this and it works when all fields are text fields on the PDF. Not sure on the other field types.
This code should not be used in a production environment as written here. There is no guarantee that the origFileLocation or newFileLocation references a PDF and no error handling among other issues. This is for demonstration purposes only.
Is there any way to populate the report viewer Dynamically (only labels)?, i what to make a little process where the users can define the label and position on the report, for example:
A)User pick this 2 fields:
1)Beneficiary Name
2) Amount of the payment
B) User pick the position of each label (or better with a drag/drop)
1)Beneficiary: Heigth = 30, width = 200, x = 20, y = 60
2)Amount: Heigth = 30, width = 80, x = 400, y = 60
C) We populate the report viewer so the user can see how his report is going to print.
Once the user save is report and want to print a Check/Payment, by code we only are going to take the label and position and send it to the print directly ("p.print()") not with a ReportViewer control, i only want the report viewer so the user can see how their report will see before printing it (position preview), or there another way to do this?.
I hope you get my idea of what a want to do here, thanks in advance.
(i use an example of 2 fields, the user will select between 30 to 40 different field)
The report definition is simply a XML file (text). As part of your report generate/run process, you could alter the contents of the .rdl file
Start by making a report template that has your fields on the report (with default positions).
Before you run the report, read template, replace (reposition or hide) those fields, save copy under a temp name.
Use your report viewer to run the (modified) copy.
I'm not saying it will be easy though. Your requirements sound tough.
The drag/drop resizing and add/removing controls (that you described) would probably have to be done using some pretty slick JQuery. There are plenty of nice examples of that kind of thing (goog).
Take a look at ReportBuilder. It allows user to create adhock reports on the fly.
I have a rdlc report that conains a tablix, nothing other. The Tablix expands in horizontal direction to show days and in the vertical direction to show groups.
The tablix works as expected, as long as I set the width of the content area equal to the width of the tablix.
If I expand the content size to its fixed size (approximately PageWidth-PageBorders) and run the report, every second page is an empty page.
However the tablix only uses one page. Every odd page is absolutely empty. It seems that the tablix adds its horizontal expansion to the currently definied content width and calculates then the overflow.
The reportviewer Version is 3 (2010 Redistributable)
Does someone have a solution for this odd behaviour?
Update
If I export the report to excel, I see that there is on the right site of the tablix a column that is exactly as long as the generated items for the days. It seems realy to be a bug or a feature I don't see how to deactivate.
I also have tried to create the same construction from a table, and it resulted in the same problem, what not is astonishing, because the table is internally also a tablix.
Update 1
If I set the property "ConsumeContainerWhitespace" of the report to true, the above test version works. But if I place then other elements in the "white" area, the effect reocurrs.
Setting the page-property ConsumeContainerWhitespace=true (in the properties dialog, F4) has helped. However it was anyhow tricky to build the report correct. At the begining it worked only if I added all extra content to the page-header and footer. But this was not acceptable. After a lot of trying, I succeed in making the report as desired. However I don't really understand the logic behind.
I have in mind that I already have done such reports (growing in both directions, horizontally and vertically together) without any problems and I don't know what is difference to this report here. For this report, it's definitively reproducable that the ConsumeContainerWhitespace-property makes the difference. But why this never happens to me for similar reports I have done, I don't know. Also I don't know why I had first to circle around before the layout-engine accepted my design.
The best way to solved this problem is, for example for an A4 page where
Width=21 cm and Height=29.7 cm
Now Margin Left=1 cm and Right=1 cm so you are having a usable width of 19 cm.
When you have understand this basic calculation that means your problem is solved. You can set up the report page size properties by right clicking on the report property => pagesetup.
I was working with an RDLC report that was printing an extra blank page. I tried all the usual tricks, and everything I could think of, until I realized the problem was caused by an extra amount of visible whitespace in the right margin area of the report. One of the objects in the report (a "Rectangle") was a single pixel or two too wide, and this prevented resizing the visible space of the report. Once I removed all the extra width, the report started printing with the expected number of pages.
Visual Studio 2017 (15.7.5) + Microsoft Rdlc Report Designer extension (v14.2)
I had a similar problem, I solved it this way
For instance for width, the following equation should be satisfied
PageSize >= LeftMargin + BodySize + RightMargin
where to find BodySize?
Press F4 -> CLick somewhere inside the report -> you will find body property(look at size property, take the width value)
Where to find report PageSize?
click somewhere outside the report -> you will find report property ( look at PageSize (take its width value), and margins (Left, right, ..), take left and right margin values)
take values from these properties, and check if they meet
PageSize >= LeftMargin + BodySize + RightMargin
Check the "body" size, try to make it as wide and height as your real paper size but reduce only the margins.
There is a confusion there on the page design. Developers would think the report being designed is WYSIWYG, but actually it's NOT!! Microsoft reportviewer will take your designed page as the content!! and append the margins defined on the outside of your page, and turn out that your page can never fit in to one page!!
So, when you design a new report, focus on the content area, the client area, including your headers and footers, and allow margins to be appended on your outer border.
the solution is simple ConsumeContainerWhiteSpace=True (you find this in the property window for "report") you set the paper size in the main menu/ report/report properties for example to "A4" and then you check that paper size is larger then body + header + footer + margins.
I was having the same issue until I played with the report body's height and width. :)
Please select "Report" in the object selector at the top of the window.
and make the ConsumeContainerWhiteSpace = true
if the also same problem persist then, your rdlc report size should be less than your report body.!
I have meet this problem recently.
The root cause may be:
your report's body has some blank upside report Footer or somewhere else.
The solution is :
1, click the report body
2, go to the property window, you will see the body size property
3, check the body size, you may find a strange number like 9.6654in,1.5625in.
that means you have some blank upside the Footer, modify the height or width size till there is no blank you can see.
Go to Property F4
Select Body
Write width and height to 1cm
Visual studio will overwrite to the smallest Body possible
Done.
You need set report width property to actual print page width. In my case 6 inches helped.
You need to make sure your RDLC Report have :
ConsumeContainerWhiteSpace = true (open by click F4)
Report Body Size <= Page Size+margin Size. (open by Ctrl + Alt + D)
Page Footer may cause the problem too. So if you have one, it's better to place it as near as possible to the main content. In this case you don't need to set the Body.Height property.
My 4x2 inch label was printing 3 extra pages for a one page report.
To fix it, I reduced the Body.Size attribute to be same or smaller than the Report.PageSize minus the summed respective Report.Margins.
Try this one,
Just make sure that all Data the needed is in the report,
Then Select the Table or the Matrix and make it squeeze to the left and if needed to the Top Left Corner until your white Page Problem is Done.
But make sure that the cells are squeezed in the right manner, Be gentle (I hope you got it !!)
Ok, Bye
Or you can just graphically resize your report design, to the exact bottom of the last report control or label.
Or add a footer section to create some space.
I thought this important enough to put here, especially since every day more of the critical information we need to do our jobs keeps disappearing:
From response to The "Every Other Page Is Blank" Feature
Many Reporting Services users ask this question:
"I'm rendering to a physical page format (PDF, Image, Print) and for
some reason a blank page gets inserted between all of the other pages
in the report. Thank you, Reporting Services, for the free pages.
It's a charming feature, but paper ain't free and I'm getting paper
cuts pulling out every other blank page after it's printed. How do I
make it stop?!"
To which I reply:
This is almost always caused by the Body of your report being too wide
for your page. Make sure that the Width of the Body is less than the
physical page size, less the margins. For those of you who are into
the math thing, make sure that:
Body Width <= Page Width - (Left Margin + Right Margin)
For physical page renderers, it's important to keep in mind the
concept of Usable Area. The Usable Area is the amount of space left
on a page for your report to be drawn after reserving space for
margins, headers and footers, and column spacing (for multi-column
reports).
Horizontal usable area:
X = Page.Width - (Left Margin + Right Margin + Column Spacing)
Vertical usable area:
Y = Page.Height - (Top Margin + Bottom Margin + Header Height + Footer
Height)
Any time objects on your report (including the Body itself) extend
past the usable area either because they are defined like that or
because they grow at runtime, the physical page renderers have no
choice but to break onto a new page.
Make sure Body size is cm , not in(inch)
For me when I increase the width for pagesize report from 21 to 23 cm , It was not generating extra empty page.
Because of few elements total size of my report's element was greater than 21 and less than 23, that is why I changed to 23cm and works for me.
In my case I have only one page and I was working with .rdl file.