
This file contains information about:
REPTW : Report Writer Use of Printer Drivers      

******** THD201.DBF ********
Msg#:  129148   Date:  06-Aug-91
Fm: Roger Bischoff [Fox] 76177,3001
To: Barry Schlossberg, M.D. 72155,774 (X)

-Barry:

The printer drivers are functioning the way they are suppose to.
There are two possible ways to print a report using printer drivers.

Process 1
---------
When you create the report, choose the printer driver you want to use
for it. Do this by selecting the Page Layout option under the Report
menu.  At the bottom of the Page Layout dialog, you will see a
checkbox for 'Printer Driver Setup . . .'.

Then, when you are in the Report dialog from the Database menu, check
the 'Set Printer Driver' option.  Selecting this option will tell
FoxPro 2.0 to use the printer driver saved with the report, and not
the one selected via the file menu.

Process 2
----------
Ignore the 'Printer Driver Setup . . .' option in the Page Layout
dialog of the report writer.  Instead, select a printer driver using
the Printer Setup dialog from the File menu.  Next, select Report from
the Database menu and uncheck the 'Set Printer Driver' option in the
Report dialog.  Unchecking this checkbox will tell FoxPro 2.0 to use
the currently selected printer driver setup via the File menu.

Apparently, you do not have the correct printer selected in the
Report, or you are telling it to use the wrong printer driver.  Try
these suggestions and let me know what happens.

Roger [Fox]

Msg#:  139759   Date:  27-Aug-91
Fm: Toni Taylor [Fox] 76702,1237
To: Jim Slater 76367,1735 (X)

Jim,

At this time, the printer drivers, will only intercept the codes that
are included in the Style Dialog.  You can however, add to the printer
driver so that it will interpret your style codes.  These codes (that
you type in the STYLE dialog), must appear in quotation marks.

Toni-

Msg#:  128519   Date:  05-Aug-91
Fm: Roger Bischoff [Fox] 76177,3001
To: Lisa Slater 72077,2417

-Lisa:

The _code_ box in the 'Style' box of the report writer is for FoxPro
2.0's own use.  This is not intended to be used for codes sent
directly to the printer.
If you notice, selecting 'Bold' will add a 'B' in the CODE dialog.
Similarly, all of the other selections will add a unique code ID to
the code box.
These codes are interpreted by the printer drivers which send Control
Codes based on the contents of 'Code'.  If the code contains a 'B',
then the printer driver finds the Control Code for BoldFace and sends
it to the printer.
If you wanted to change these codes, you will have to modify the
'Gen_Pd.Prg' and add another condition test for your own personal
codes.

I hope this helps.

Roger [Fox]



******** THD202.DBF ********
Msg#:  165266   Date:  22-Oct-91
Fm: Glen Harness 73277,137
To: Lisa Slater 72077,2417 (X)

First off, I'm glad to have gotten to meet you at DevCon; it's always
good to put a face with a name.

Got an interesting question for you.  I keep a little mailing list
here for my department.  It currently has about a 100 names.  The dbf
is set up something like this:

     1  DEPARTMENT  Character     35
     2  FIRST_NAME  Character     10
     3  LAST_NAME   Character     10
     4  CAT         Character     12
     5  DEPT_NO     Numeric        3      0
     6  KEY         Character      1

My master index is STR(DEPT_NO,3)+KEY+LAST_NAME+FIRST_NAME.  This lets
me control the actual index order, so that the supervisor of the
department comes out before all the others in that department (eg,
supervisors have a KEY of 1, everyone else has a key of Z).

What I'm doing now is a control break on DEPT_NO, and printing
DEPARTMENT at that break. What they want me to do is to BOLD the
department name in addition to the supervisor's names, ie the first
name after the break.  I can use the STYLE check box to bold the
department name, but how do you bold only the first line after a
break?  I got a feeling I may have to assign all the supervisors a
particular key, and do a second break on that. Or use some kind of
funky report variable.  Any ideas?

Glen

Msg#:  165297   Date:  22-Oct-91
Fm: Lisa Slater 72077,2417
To: Glen Harness 73277,137

Use overlaid report expressions for this, I think, same as you'd do it
in 1.02 with the additional aid that the existing pdriver can give
you.

Place a report expression that starts at least one char to the left
the supervisor's name, make it long enough to hold all the escape
codes it might have in it.  The expression is something like this:

   IIF(the_key = "1", _PDARMS(11),"")

Start another report expression *after* (to the right of) the
beginning of the name report expression, or after the beginning of the
second name if you've got the first and last name divided into two
expressions.  Make sure it is long enough to hold everything, too.
This expression could simply be
_PDPARMS(12)

.. since I don't think sticking a "bold off" code in there every line
will confuse the printer, or you could make it an IIF() as above.

Note that this will work as long as you have a pdriver loaded.  If you
think that maybe you will not always have one loaded, you can write it
like this:
   IIF(the_key="1" AND TYPE("_PDPARMS(11)") = "C", _PDPARMS(11),"")

You could also separate this out so that the TYPE() evaluation is done
only once at the beginning of the report; initialize a report var for
each of the two array elements like this:

   IIF(TYPE("_PDPARMS(11)") = "C",_PDPARMS(11),"")

.. storing their own names to themselves and never re-setting.  Then
your report expressions read:

   IIF(the_key="1", reptvar1,"")

.. this may run a little more efficiently, although I haven't checked,
and also allows you to store default printer codes in reptvar1 instead
of a null string if no pdriver is loaded and you care to do this.

With overlaid expressions like this, you'll probably have to play with
"front/back" a little bit to get reports to the screen and previews to
show up exactly as you'd like.

>L<

Msg#:  165832   Date:  23-Oct-91
Fm: Glen Harness 73277,137
To: Lisa Slater 72077,2417 (X)

Thanks... I'd actually been doing something similar to that in 1.02,
but for some reason, I had used an actual database field to put the
enhanced off code into.

I wasn't quite sure where you were getting the "the_key" part of

   IIF(the_key = '1',_PDPARMS(11),"")

I tried it a couple of ways, and had varying amounts of success.
Anyway, it got me to thinking, and I suddenly realized that all the
records that I wanted in bold were in all upper case.  So, it was a
matter of basically modifying your line above to this:

   IIF(ISUPPER(SUBSTR(lastname,4,1)),"_PDPARMS(11),"")

I'm using the 4th character in the name because some names do have
some lower case letters, like McRIGHT and DePRIEST.  But it works...

Thanks again for the help... Glen


Msg#:  165932   Date:  23-Oct-91
Fm: Lisa Slater 72077,2417
To: Glen Harness 73277,137 (X)

Oh!  by the_key, I meant the field you wanted to check for a code that
indicated a supervisor, which (I thought you said) holds a "1", no?
If it doesn't hold a one, it holds *some* supervisorial code <g>.

The whole point is that I am not checking the first record after the
group header, although there is an easy way to do this also, using
report variables. I decided it was better to check for *supervisor*,
regardless of the position of the record in the detail, in case you
suddenly decided to list folks within a dept by name instead of rank.
Since you can bold the supervisor's name and no other's it makes
sense, in fact, to bold the supervisor but otherwise have an
alphabetical listing by dept, don't you think?  Very nifty.

And if you use an EVAL() instead of "the_key = '1'" in your IIF()
expression, your clients can choose to bold *any* employees within
depts, by *any* criteria, at runtime!  Let's assume your the_key field
has grades up to 6; you could bold everybody where
BETWEEN(the_key,1,3)... or let's say you have a field that indicates
when they transferred in to the dept, you could bold everybody where
datefield>somedate, to highlight new folks for special attention...
all without changing the report in any way, just provide a dialog to
let them specify such things...

You like? <g>

>L<



******** THD203.DBF ********
Msg#:  182064   Date:  24-Nov-91
Fm: Jordan Powell 74206,2521
To: David Gibson 100015,2106

I have had the same problem when using the report writer. This is
subject to correction but here's what I found. I send the output to a
file and then looked at the strings being sent to the printer. Seems
that FoxPro's printer drivers send a string to the printer telling it
to assume that the physical form length is equal to the length, in
lines, specified in the report.
In other words if you tell the report writer you want 42 lines per
page the printer driver sets up the printer as if the physical size of
the page is 42 lines (even though it is usually more). So I remobved
the command to set the page length from the file and then sent ot to
the printer and everything worked out fine.

To fix this I intend to modify the pc_codes database to remove the
page length code (set it to null) so that the page length will not be
reset. Then I guess I have to rebuild the app.

I find it curious that Fox assumes that the number of lines I want to
print per page is always equal to the physical page length.


******** THD205.DBF ********
Msg#:  202972   Date:  13-Jan-92
Fm: Lisa Slater 72077,2417
To: Erik L. Rogers 70323,1673 (X)

This isn't really all that hard, if regular and compressed is all you
need.

You set the pdsetup to the default for that person, fine. You
understand the elements 8 and 9 of _PDPARMS, great.  Now leave _PPITCH
out of it <g>.  This sys var is only included so code brought in from
dBase IV doesn't bomb; it isn't used by the pdriver system. But once
the driver is set you can
??? _PDPARMS(8) to make sure to set to normal

and

??? _PDPARMS(9) to make sure to set to compressed,

from a UDF() in your report.  If you have a title band, stick it in
the first position of the title band.  Otherwise, initialize a report
var to this UDF() and then store 0 to it afterwards or something,
because you won't use it except at the very beginning of the report.
You only need to do this once, because we're not going to "associate"
it with any of the report objects...
Why not just ??? the element before running the report, you say?
Because the PDDOCST procedure (on document start) will otherwise
override it.  You could, alternatively, write a user procedure to add
to your docstart printer drivers that would accomplish the same thing
-- this is actually simple to do and more "one with the Two" <g>.  The
procedure would check a variable to see if the current report is
supposed to be compressed; if so it would take the param that FoxPro
passes to it automatically and
STRTRAN(the_param,_PDPARMS(8),_PDPARMS(9)).

Either way, if you are using any Style codes in your reports (bolding
or whatever enhancements) you'd need to do the same thing in a couple
more user procedures, like the object-end one I think.

Take a look at DRIVER.PRG so you can see how the userprocs are called;
this is really incredibly easy and kind of fun <g>.

>L<

******** THD206.DBF ********


Msg#:  213900   Date:  05-Feb-92
Fm: Chris Pudlicki [Fox] 76702,1237
To: Chuck Werner 71740,233 (X)              -Chuck

In your assessment of the printer drivers you are correct in most all
cases.
Placement of your algorithm really depends on when you want it
executed, IMO, you are correct in placing it in the PDPAGEST
procedure.

The extra page that you notice is due to how the page start(ps), page
end(pe), line start(ls), and line end(le) procedures are called.
First, ps and pe are always called in pairs, so for every ps there is
a pe.  Second, pe always calls ps when ls and le have printed a detail
line even if that detail is an empty line to represent the EOF.  This
provides for the possibility of what seems to be an extra page.

What you can do to prevent your PDPAGEST procedure form being called
again is to set up a flag value to control the execution of PDPAGEST.

Regarding your question about something changing the values of
_PDPARMS, the only thing that effects the values are the programs in
GENPD.APP.  Which programs, depends upon whether you are using the
xbase version or the .PLB version of the drivers.

--ChrisMsg#:  214831   Date:  07-Feb-92
Fm: Chris Pudlicki [Fox] 76702,1237
To: Chuck Werner 71740,233 (X)

-Chuck

What you would want to do is check the flag status in the page start
and flip it in two places, page end and on the detail line.  The
detail line will not be called if nothing is printed on the page,
hence the flag will not be changed from its status as set in page end.

--Chris


******** THD07.DBF ********
Msg#:  247636   Date:  14-Apr-92
Fm: Chris Pudlicki [Fox] 76702,1237
To: Steven Black 76200,2110 (X)

-Steve

There message "Printer driver removed" occurs when you run into a low
memory situation and in an attempt to avoid problems FP removes the
printer driver from memory.  The printer driver is  removed in an
attempt to avoid more serious complications due to lack of memory.

It sounds like you are either running with limited memory or your
report is very complex and needs a lot of memory.

--Chris

Msg#:  252330   Date:  24-Apr-92
Fm: Guenter Huber 100023,1502
To: Anthony DiFazio 71241,2021

Anthony,
be sure to use right-justification with numbers and proportional
fonts! G
Msg#:  270948   Date:  07-Jun-92
Fm: Lisa Slater 72077,2417
To: Eldor Gemst 75300,2370 (X)

The advantage to setting _PADVANCE and _PLENGTH explicitly is twofold:
1.) It's right in the code and it is very clear;

2.) It is *not* printer-specific <s>.  You don't have to create such
code entries for each printer individually.

IMHO there's no good reason to do it the other way...

About the relationship between _PLENGTH and the report layout:

The report layout number of lines figure takes precedence over
_PLENGTH, or possibly even resets _PLENGTH for the report run.
However, _PADVANCE looks only at _PLENGTH, I think (I could be wrong
about this) so JIC I always set _PLENGTH to match.  (There is that
pesky possibility that if you do an EJECT BEFORE it will come out
wrong because you're not really "in" the report form yet. IOW the
order in which things happen in the RW is spectactularly complicated,
so I'd rather have the insurance than worry about all the
permutations.)

Matching the two figures is not a difficult thing to do, since you can
alwayse USE the.FRX to check the first record's Height field to find
out what the _PLENGTH value ought to be.

>L<

Msg#:  226969   Date:  03-Mar-92
Fm: Mike Reed - CompuSolve 76266,3724
To: SYSOP (X)

I noticed that if I run a REPORT FORM ... PDSETUP that the proc
PDOBJECT executes for every object in the report.  While this makes
sense if the object has a STYLE checked off, why DO PDOBJECT for every
object even when **no** style attributes are set on any object ?

Seems to me that this will unnecessarily slow down reports ...

I observed this behavior with a printer setup based on HPLJ's running
a REPORT under FOXPROLX dated 11/14/91.

Thanks, Mike

Msg#:  227395   Date:  04-Mar-92
Fm: Chris Pudlicki [Fox] 76702,1237
To: Mike Reed - CompuSolve 76266,3724

Mike -

You are correct.  At this time, FoxPro does not check to see if any
objects have a STYLE selected.  This sounds like a good idea, though.
I'll submit this as an ER for you.

Elaine [Fox]

Msg#:  252835   Date:  25-Apr-92
Fm: MAX W KUYPERS 73730,1543
To: Lisa Slater 72077,2417 (X)

Lisa, Congratulations on the book. I just wish I had had it 6-8 months
ago. I probably wouldn't have had to ask some of the very basic
questions you helped me with. Now however, the book still leaves me in
the air regarding modification of the printer P_Codes.
I want to modify one of the OKI printer codes to the codes for one
that is not listed, i.e. OKI 380. I had asked Chris Publicki about
this and he mentioned that I must enter the codes as CHR(x), but not
on how to actually enter these codes. If, as you describe on page 566,
I use Scatter to memvar,Append blank,Gather to enter the new codes,
how do I actually enter say CHR(27) CHR(15) to get the equivalent
control code in the field?

Could I not also open the P_Code dbf, select the printer to modify,
and then do an Edit of that record?

Once I have the correct codes enter and I go to Modify Project and
select Genpd_App, do I select rebuild or build?

I have checked all the Printer reports in the library but found no
mention of how to actually enter these codes or how they get converted
to the control equivalents.

Thanks for your time and help.

Max:


Msg#:  252854   Date:  25-Apr-92
Fm: Lisa Slater 72077,2417
To: MAX W KUYPERS 73730,1543   

Thanks for writing, Max.  I'm glad the book is helping you.. this
information is actually *in* there, although I agree it's not a
particularly intuitive process.
One way you can do what you want is REPLACE this_field WITH
CHR(27)+CHR(whatever)...  Take a look at what ends up in there. <g>
Another way is to use the Alt and numeric keypad way of entering the
ascii values for things directly into the browse'd field.  This won't
work in all cases, though, CHR(27) (the ESC character) being one of
them.

For your CHR(27) if you want to enter it into the BROWSE'd field
directly, I think the best method is to STORE CHR(27) TO _CLIPTEXT,
then you can CTRL-V it right in there interactively.  Most of other
stuff is a piece of cake with the alt-numeric keypad and the ascii
chart to help you out...

As is also explained in the book, you should BUILD APP.  There's very
little reason to BUILD PROJECT again after a project is existing.

>L<
