Using ReportBuilder 7.X
Question
Is it possible to Control Print to File.
I need to change the Length of a field at print time
Example:
label2
In the setup - I set its length to 800 which is the max possible this field should ever be.
However, in many cases the record is less than that and i need to set it to the calculated size before printing to file.
Is this possible?
Is it possible to control any portions of this Print to file...at print time (before Print, after print)?
Are the objects avaiable?
We are registered users of the 10.x and above i believe, but have still not gotten around to recompiling are application in Delphi 2009 and the new ReportBuilder....so, that is not an option at this point.
Thanks
Shane
You can try to use the OnDataChange event of the tDataSource that you are using to link your data to your report. This event fires when the current record in the associated dataset changes. In that event, adjust your label to the size for the current record.
i solved this! Each control has a saveLength property. I can just use a global variable that can change at any time (controlling length of entire record). Then just before i print he label, i can set its saveLength property
thanks to all who responded though
Related
I have a problem that I can't seem to get rid of.
When a customer of mine prints a specific QRP, he gets a "WARNING. This report may extend beyond the printer page margins. Text may be clipped, depending on the printer in use. Do you wish to continue?"
While of course in no way critical, it's a problem due to the sheer number of prints per day this customer has, having to confirm this dialog every time.
I've had this issue before and seemed to be able to fix it by setting the report format to "Custom", but I've recently updated the QRP and the problem is back despite being still set to "Custom". I have also tried A4 (which is the printer's standard page format) and A5, to no avail.
Is there maybe a way to suppress this error in code?
The report itself is way smaller than A4 (it's an A5 format packaging label) so there is no way it would lead to any problems with the print margins, and the prints do come out perfectly fine.
You can use the constant RPT_PrintNoWarn along with SalReportPrint function. The constant is used for suppressing warnings about margin overflow and tiled pages.
It can be combained with constant RPT_PrintNoErrors using pipe symbol.
SalReportPrint ( hWndFrm, strTemplate, strVariables, strInputs, nCopies, RPT_PrintNoWarn|RPT_PrintNoErrors, nFirstPage, nLastPage, nErr )
I'm developing a cashier application using Delphi 7 and QuickReport 3.0.9.
The problem is the printing module is limited to the size of the component length in the form, so when the user prints a very long list of item, some of the items will get cut off. The printer is a special printer for cashiers (I don't know the correct name for this printer) that uses a roll of paper, so the printout length should be unlimited.
How do I set the printout length to unlimited? I already emptied the QuickRep1 - Page - Length property but it's still cut off at some point.
Unfortunately you cannot do it with QuickReport v3.0.9.
Support for continuous paper has been introduced with QuickReport v5 update:
Continuous paper. A new property of TPage, Continuous adds support for printing from rolls
When you set the Continuous property to true, the report should not contain any newpage commands.
Using Delphi XE, I have a JvCsvDataset component that is loading a CSV file which has 27 fields.
When the component tries to load the file I get the following error :
Too many fields, or too many long string fields in this record. You must increase the internal record size of the CsvDataSet.
When try it with a CSV file that has only 24 fields, it works fine.
How do I increase the internal record size of the CsvDataSet?
I've tried to reach Warren Postma who wrote the component but did not hear back from him.
Either specify the length of your fields to stay under the default limit or set the value of TextBufferSize to a bigger value before setting active to True.
From the last answer on
http://issuetracker.delphi-jedi.org/view.php?id=4768
I am developing a billing system using PowerBuilder 12.5 Classic and I need to set 0 for a textbox; like in vb.net txtchange.Text = 0
i have two drop down list boxes
ddlb_price (defines the price value of an item)
ddlb_cash (the cash amount given by the customer)
sle_change (the change that the cashier is to give the customer)
the system should set the value for sle_change when the cashier inputs the cash.
1. this gives me syntax error;
if cash=price then
sle_fare.settext=0
end if
2. this gives 'incompatible types in assinment
if cash=price then
sle_fare.text=0
end if
The single line edit (sle) control is designed to hold text. You're trying to assign it a numeric value. You will have to change the number into a string if you want the sle to display it:
sle_fare.text = "0"
or
sle_fare.text = string(variableHere)
Once again, I'm going to step back, ignore the actual questions, and look at how a DataWindow would help as an alternative.
You seem to want a control with a data type behind it. The DataWindow has those types of controls. Don't forget that a DataWindow doesn't have to have a SELECT statement behind it; it can have a stored procedure, web service, or nothing at all (external DataWindow) behind the data set. Once you have a control with a numeric data type behind it, you get (for free) some basic editing controls, such as not allowing alpha characters in the field and making sure the entered value is really a number (e.g. "0-.2.1" would fail).
A step beyond that is looking at one of your coming requirements: calculating change. On a DataWindow, you can create a compute with an expression that will automagically calculate your change for you, once price and cash are entered.
I certainly don't want to say you can't do things the way you're proceeding, but there are many issues that a DataWindow would remove over some other approach. The strength of PowerBuilder is in the DataWindow.
Good luck,
Terry
Nevrona Designs' Rave Reports is a Report Engine for use by Embarcadero's Delphi IDE.
This is what I call the Rave Endless Loop bug. In Rave Reports
version 6.5.0 (VCL10) that comes bundled with Delphi 2006, there is a
nortorious bug that plagues many Rave report developers. If you have a
non-empty dataset, and the data rows for this dataset fit exactly into a
page (that is to say there are zero widow rows), then upon PrintPreview,
Rave will get stuck in an infinite loop generating pages.
This problem has been previously reported in this newsgroup under the
following headings:
"error: generating infinite pages"; Hugo Hiram 20/9/2006 8:44PM
"Rave loop bug. Please help"; Tomas Lazar 11/07/2006 7:35PM
"Loop on full page of data?"; Tony Chistiansen 23/12/2004 3:41PM
reply to (3) by another complainant; Oliver Piche
"Endless lopp print bug"; Richso 9/11/2004 4:44PM
In each of these postings, there was no response from Nevrona, and no
solution was reported.
Possibly, the problem has also been reported on an allied newsgroup
(nevrona.public.rave.reports.general), to wit:
6. "Continuously generating report"; Jobard 20/11/2005
Although it is not clear to me if (6) is the Rave Endless loop bug or
another problem. This posting did get a reply from Nevrona, but it was
more in relation to multiple regions ("There is a problem when using
multiple regions that go over a page-break.") than the problem of zero
widows.
This is more of a work-around than a true solution. I first posted this work-around on the Nevrona newsgroup (Group=nevrona.public.rave.developer.delphi.rave; Subject="Are you suffering from the Rave Endless Loop bug?: Work-around announced."; Date=13/11/2006 7:06 PM)
So here is my solution. It is more of a work-around than a good
long-term solution, and I hope that Nevrona will give this issue some
serious attention in the near future.
Given your particular report layout, count the maximum number of rows
per page. Let us say that this is 40.
Set up a counter to count the rows within the page (as opposed to rows within the whole report). You could do this either by event script or by a CalcTotal component.
Define an OnBeforePrint scripted event handler for the main data band.
In this event handler set the FinishNewPage property of the main data band to be True when the row-per-page count is one or two below the max (in our example, this would be 38). And set it to False in all other cases. The effect of this is to give every page a non-zero number of widows (in this case 1..38), thus avoiding the condition that gives rise to the Rave Endless loop problem.
Thanks so much for this Sean - unfortunately this wouldn't work for me but I came up with another solution...
You see I have a memo at the top of the region that might expand or contract depending on how many notes the user has left in the database. This means that the number of rows that can fit on a page varies.
However. there is another solution - you use the MaxHeightLeft property of a databand.
All you do is measure the height of your databand, multiply it by 2, and put this in your MaxHeightLeft property. This will force 1 or 2 records onto the next page if it fills up that much.
thank's a lot, this thread helps me out from my problem with endless printing loop in Nevrona Rave...., I set MinHeightLeft to 0,500, this setting is work but i'm not sure that it will work for anothers result set of my query report.
Master,
The solution is MinHeightLeft to 0,500 , i use property wastefit area in true and generated the loop in the second print, but when changed the property MinHeightLeft to 0,500 the error disapear.
Thanks !
Atte
Fabiola Herrera.
Fabi_ucv#hotmail.com