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 )
Related
Retro printer day: I have an old IbmPro compatible dot matrix printer connected by a USB parallel adapter to my Ubuntu 20.04 system. It works great! One major trick in setting it up: set the URI to /dev/usb/lp0 and make sure the lp user is in the right group to write to that dev. That took me a while to figure out. I use the IBMPro generic printer driver and it's great. Other critical hints: 9600 baud, 8 bits, no stop bit, hardware flow control.
The one remaining problem: the print area is offset about 0.5" to the left. I'm sure I know what's going on: the tractor feed area is about 0.5" and so I need to somehow indicate, don't count the tractor feed area within the page margin. In other words, the full page width is about 9.5" but only print 8.5" of that and offset it 0.5" to the right.
I've tried editing the PPD file including changing the values in HWMargins and ParamCustomPageSize WidthOffset. None of this seems to have any impact. I've read a bunch of documentation about PPD files and it's just not clear what to do. I guess I could set up a custom paper size of 9.5" width but I would prefer to just have all my documents be the same and print correctly by offsetting everything as it's generating printer output.
There must be a simple setting for this.
Edit: tried a lot more things including:
Go to Printer Properties and go to Job Options. There's a left margin setting. I set it to 36 points, or half an inch, and that moved printing over. Adjust as desired. But that didn't work. I also tried to make this change in the PPD:
ImageableArea Letter/US Letter: "18 36 612 756"
and that didn't work.
It is fixed. The order of parameters for the gs line in the PPD must be just right and it's not obvious how to get it working. After much trial and error, this line works:
*FoomaticRIPCommandLine: "gs -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE &&
-dNOMEDIAATTRS -dNOINTERPOLATE -sDEVICE=ibmpro%A%Z &&
-sOutputFile=- &&
-c "<</PageOffset [36 0]>> setpagedevice" -f -"
It must be in exactly that order. Adjust the offset values (36 for the horizontal offset, 0 for vertical, in this case) as needed. This really should have been easier, given that it's going to be quite normal to adjust offsets on any dot matrix printer. I hope this question is useful for anyone else in this situation. Yes do pay attention to the HTML escapes used in the line above, they are correct. I tried before using ' and that didn't work. It must be ".
This was really a lot of effort to figure out although would probably be obvoius to someone experienced in PPD files.
I need to use maxima software to deal with data. I try to read data from a text file constructed as
1 2 3
11 22 33
ect.
Following comands allow for loading data sufficiently.
load(numericalio);
read_matrix("path to the file");
The problem arises when I apply them to a more realistic (larger) data set. In this case the message appears Expression longer than allowed by the configuration setting.
How to overcome this problem? I cannot see any option in configuration menu. I would be grateful for advice.
I ran into the same error message today, at it seems to be related to the size of the output that wxMaxima receives from the Maxima executable.
If you wish to display the output regardless, you can change it in the configuration here:
Edit>Configure>Worksheet>Show long expressions
Note that showing a massive expression or amount of data may dramatically slow the program down, so consider hiding the output (use a $ instead of a ; at the end of your lines) if you don't need to visualize the data.
I know that attachments can be short:true or short:false, but it seems to me that even when they're short:false there is still a maximum length which is shorter than the regular length of a message.
Can this be controlled?
Thanks.
I know this is an old question, but it was high on my GOOG results today, so thought I'd post my solution here.
Short version - I stopped using attachments and put everything in the text.
Long version - my use case was using the color-bar on attachments to display info/warn/error info, but ultimately the line-wrap was making it less useful. The alternative is to set the sender name and icon_emoji to indicate that info, and simply put the log data in the text. For my case, we don't have log data longer than the 4k limit, or else I'd use a files.upload approach to get text snippets.
Hope this helps!
You mean character width? This seems to be 78 characters (80 less 2 characters for the coloured bar?)
Unfortunately no, you do not seem to be able to change the width (at time of writing). You can resort to text which is full width.
short is for side by side fields only, not the entire attachment.
Also see Slack Attachment Width and Wrapping Issues
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
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