I am having a problem when my program is installed to another computer, where its printer preference is different, where my data report accepts Letter size 8.2 * 11 in, because when the printer preference is different the data report well not show and gives an error saying the page width is larger than paper width, does anyone know how to fix this problem.
i tried this code but it didn't work
Printer.PaperSize = vbPRPSLetter
Check out the Microsoft KnowledgeBase article FIX: Error Message "Report Width Is Larger Than the Paper Width" When Showing Data Report in Landscape
When using the Show method of Data
Report to preview the report, the page
orientation defaults to the default
printer settings on the local
computer. Therefore, if the
orientation of the default printer
settings is set to Portrait of
standard Letter paper and your report
width is more than 8.5 inches wide,
the following error occurs: Report
Width is Larger than the Paper Width.
The solution appears to be setting Orientation before using the Data Report. Change DataReport1 to the name of your data report.
DataReport1.Orientation = rptOrientLandscape
DataReport1.Show
EDIT Another suggestion: Microsoft offer a free DLL that allows you to change the default settings for the printer. You could try using that free DLL in your project, then do something like this code below before using the data report. Microsoft say "this DLL is particularly useful when dealing with the Data Report, which reads the default printer orientation prior to displaying or printing a report."
Set obj = New PrinterControl
obj.ChngOrientationLandscape
-Can you just switch to a custom paper size?
Printer.PaperSize = 256
Printer.Width = 11808 '(8.2 * 1440)
Printer.Height = 15840 '(11 * 1440)
-Are you sure the error isn't related
to the maximum print width of the
report itself? Many printers have a max print width
that forces 1/4" margins on either
side of a paper. Which in your case forces your printable area to be 7.7" max. Quickest way to
check would be to temporarily set
the print wide to a lower value and
see if it works.
-Another possibility could be permissions to the printer. If it's a shared network resource it may be locked down and be rejecting the changes to the paper settings and throwing an inaccurate error msg.
To change Printer orientation at runtime, we need to install VB6 Service pack 6
Use this code
DataReport1.Orientation = rptOrientLandscape
DataReport1.Show
This will work fine
Related
I am trying to print the images from the ioComp iPlotX object to a PDF printer. This object has iPlotX.SaveToBitmap, which does work and I can 'send' the file to the PDF printer, but the image is blurry, the bitmap is 96 DPI.
The control has iPlotX.PrintChart method which is supposed to go directly to a printer. There is also a method to indicate which Windows printer to direct the output to. I fumbled around to see if I could get anything to work and a couple times I produced an image in the PDF file that was very clear. But other items printed to the page were gone and I only had one page instead of 3 pages. Most of the times nothing is in the PDF file.
A snippet of my relevant code is below.
Me.SinglePlotObject1(iIndex).PlotControl.PrintShowDialog = False
Me.SinglePlotObject1(iIndex).PlotControl.Printername = modNovaPDFConstants.NOVAPDF_PRINTER_NAME
Me.SinglePlotObject1(iIndex).PlotControl.PrintOrientation = poLandscape
Me.SinglePlotObject1(iIndex).PlotControl.PrintChart
This note is from the ioComp.Help:
Note : If you have set PrintShowDialog to TRUE and have set
PrinterName to a non-empty string, then the printer selected by the
user will be ignored! The PrinterName property will always override
the user printer selection, if you are using our printer dialog If
you plan on showing our built-in printer selection dialog to your end
user, then you should set the PrinterName property to an empty string
for everything to work correctly.
Also from their help is :
property PrintXStart : Double Used to specify the starting x-axis Min
value when implementing multi-page printing.
Description: Use PrintXStart to get or set the starting x-axis Min
value when implementing multi-page printing. By default, the
PrintXStart and PrintXStop are initialized to the Min and Max of the
x-axis display on the screen and will only print out one page. You
must manipulate the PrintXStart and PrintXStop in the OnBeforePrint or
OnBeforePrintPage event to have multiple pages print out during a
single print session.
The only example they show is setting the XStart property to 0. I am not sure if this means multiple pages for the same graph, that is, the graph is stretched out over multiple page or is this has something to with different iPlots on separate pages. In the past we have always just used the iPlotX.SaveToBitmap to print. At that time the plots and text were good enough.
If anyone has any experience with ioComp plot controls and printing, I am willing to try any suggestions.
Right now I am trying to create a test application with as little code as possible to test all of their other printer options.
I have tried their FAQ section but could not find anything related to printing using VB6 and the ActiveX controls. When I sent a message to them, a smtp error appeared.
DaveInCaz: Good Idea. I tried a different PDF printer and results are the same. I tried a method of the control called iPrintToDC, passing in the Printer.hDC. This made some progress. I can print two graphs on two pages, but the graphs are about the size of my thumb. If I change width's or height's, it only makes things worse, by somehow placing the bottom of the graph 'above' the title and removing all the contents of the graph itself; it is as if the graph is wrapped around a cylinder and all I see is where the top and bottom meet. When I used the .PrintChart method, only the last of two charts would be printed and nothing else I printed would appear.
Thanks.
I've run into a problem with CRichEditCtrl. I'd like to use a table to format a generated text to display. In the rtf 1.5 specs it says, that I must specify a table border to display any but apparently some default settings of the CRichEditCtrl sets them anyway.
This code:
CString sDoc =_T("{\\rtf1\\ansi\\deff0"
"\\trowd\\trgaph144 "
"\\cellx500"
"\\cellx3000"
"\\cellx5000"
"\\cellx7000"
"\\intbl 01 \\cell"
"\\intbl Hexachlorbenzol \\cell"
"\\intbl 500.00 mg \\cell"
"\\intbl WST \\cell"
"\\row"
"}");
EDITSTREAM es;
es.dwCookie = (DWORD)&sDoc;
es.pfnCallback = MEditStreamInCallback;
edtInfo.StreamIn(SF_RTF, es);
results in:
I've tried to set the cell's border width to 0 and borde color to white to 0.
"\\clbrdrt\\brdrw0\\clbrdrl\\brdrw0\\clbrdrb\\brdrw0\\clbrdrr\\brdrw0"
or
"\\clbrdrt\\brdrcf0\\clbrdrl\\brdcf0\\clbrdrb\\brdrcf0\\clbrdrr\\brdrcf0"
It doesn't work either way. The result is always the same.
Perhaps someone here knows how to disable this, obviously, default border.I want to to disable or hide this border. Maybe there is a setting for it in the control, i haven't discovered yet.
The Rich Edit 3 control always displays tables with borders. You can upgrade your code to use Rich Edit 4.1 if you wish to have control over the borders. If you do much with tables, you will find Rich Edit 4.1 far superior. It supports multiple paragraphs in a cell, text alignment within a cell, and more.
See https://msdn.microsoft.com/en-us/library/windows/desktop/bb787873%28v=vs.85%29.aspx for the DLL to load and the class name for Rich Edit 4.1. Rich Edit 4.1 is available on Windows XP SP1 and higher. For more information about different versions, see http://blogs.msdn.com/b/murrays/archive/2006/10/14/richedit-versions.aspx
I am using telerik reports. Some of my reports are large sized. When printing these reports not fit into default page size. I need to fit it into page by default. How can I implement this? Pls reply
Each report has a defined size in its definition which you can change and the same goes for page margins. You should also have in mind that each printer has hardware margins which is not possible to override. With that taken into account, you should be able to set an appropriate size that prints correctly. If still in dilema, elaborate on the report size, its pagesettings and the printer and paper format you're trying to print to.
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