MichaelKatz
asked on
VFP Detail 1 band is too large for page
Back to an old question. What seems to be the best workaround for the DETAIL BAND TOO LARGE error is changing the paper size to fool the printer. However, this has implications when the printer is used by other applications.
Is copying a printer and changing the paper size on the new printer a workable idea?
If so, how do you copy a printer? CTRL-C doesn't work.
Another option is to ADD a printer, but this is for a distributed APP, and is just too time consuming. I often have to work with users who are not very computer literate.
Any ideas will be appreciated.
Is copying a printer and changing the paper size on the new printer a workable idea?
If so, how do you copy a printer? CTRL-C doesn't work.
Another option is to ADD a printer, but this is for a distributed APP, and is just too time consuming. I often have to work with users who are not very computer literate.
Any ideas will be appreciated.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks Olaf,
The second option is not feasible, because this is for a distributed APP and there are too many different sites.
What about setting the report size to"Legal" and keeping the data within "letter " size dimensions. Could this cause the printer to draw paper from a different paper tray?
The second option is not feasible, because this is for a distributed APP and there are too many different sites.
What about setting the report size to"Legal" and keeping the data within "letter " size dimensions. Could this cause the printer to draw paper from a different paper tray?
Hello Michael,
Sorry, I can't help you with your last question. Perhaps, if I sometimes would get hands on a printer with several paper trays. In fact we had one in th office, but it's replaced by a more modern but simpler one.
Bye, Olaf.
Sorry, I can't help you with your last question. Perhaps, if I sometimes would get hands on a printer with several paper trays. In fact we had one in th office, but it's replaced by a more modern but simpler one.
Bye, Olaf.
ASKER
I'm beginning to think it is more than the margins or paper size. One machine actually listed the offending expression of a field, all the other times all i got was "Detail 1 band too..... The actual expression was somethibg like this. . .
iif(!EMPTY(Sales),TRANSFOR
VFP found it offensive even though the evaluated results was much smaller.
Is there a way to for an error handler to display the offending line/field ?
Michael
iif(!EMPTY(Sales),TRANSFOR
VFP found it offensive even though the evaluated results was much smaller.
Is there a way to for an error handler to display the offending line/field ?
Michael
in code, yes: search ON ERROR in the help file and it should point to LINE(), but then an expression in a report may be in a record, but it's not a line of code, it's an expression of a report control. Such things - another example is controlsource expressions or dynamic...-expressions in grids cause errors without poining to a certain control.
Maybe someone else has an idea what errorhandling related functions offer to localize such errors. Maybe there is some hint in the description of the error number. Some of the error cause extra info in AERROR() for example OLE errors or ODBC errors.
Bye, Olaf.
Maybe someone else has an idea what errorhandling related functions offer to localize such errors. Maybe there is some hint in the description of the error number. Some of the error cause extra info in AERROR() for example OLE errors or ODBC errors.
Bye, Olaf.
Have you checked to see if the report has an printer defined that is different than the actual printer that may be used by a workstation?
ASKER
Olaf,
The line number of error is usually the line of code that called the report:
Reprt Form to. . .
I still seem to think that the problem was from fields with long complicated expressions, even though they evaluated to a small simple result, and passed the field Verify test in the report designer.
I sent out an update and am awaiting results.
rr miles,
I clear both TAG fields in all reports before building the apps, so I don't think a printer definition is the cause.
I'll be back as soon as I hear something,
Thank you all.
The line number of error is usually the line of code that called the report:
Reprt Form to. . .
I still seem to think that the problem was from fields with long complicated expressions, even though they evaluated to a small simple result, and passed the field Verify test in the report designer.
I sent out an update and am awaiting results.
rr miles,
I clear both TAG fields in all reports before building the apps, so I don't think a printer definition is the cause.
I'll be back as soon as I hear something,
Thank you all.
ASKER
Thanks all.
I think part of the problem was, as I mentioned before, long complicated expressions
that appear very long in the report, even though they evaluate to something much smaller and pass the Verify test.
Also very large fonts seem to be trouble some occasionally. Possibly because they may not be present on the users machine and the substitution is not exact.
Michael
I think part of the problem was, as I mentioned before, long complicated expressions
that appear very long in the report, even though they evaluate to something much smaller and pass the Verify test.
Also very large fonts seem to be trouble some occasionally. Possibly because they may not be present on the users machine and the substitution is not exact.
Michael
ASKER
My problem is with a distributed APP, and I would not know most of the parameters.
Please keep trying.
Michael