This file contains information about:
PRINT : Printer Driver Use                        

******** THREADS2.DBF, 2.0 BETA MESSAGES ********

Msg#:  28332   Date:  26-Jun-91
Fm: Cathy Corey [Sysop] 76177,3002
To: Paul Rosner 76046,3643 (X)

Paul,

Give the following a try.  This should work for you.

USE XXX
_PDSETUP="NEC_PORT16'

SET DEVICE TO PRINT
STORE "ATHLLIST.DOC"    TO T_OUTFILE
SET PRINTER ON
SET PRINTER TO &T_OUTFILE
SET CONSOLE OFF

set libr to pdrivers\driver2.plb
*
* Or, if you are using the XBase version comment the line above and *
uncomment the line below:

*set proc to pdrivers\driver.prg

?PDDOCST(66,80)
DO WHILE .NOT. EOF()

    IF T_FIRST .OR. _PLINENO > G_PAGELEN THEN

        STORE .F. TO T_FIRST
        ? "Athletic Listing  as of: "+DTOC(DATE())+" "+LEFT(TIME(),5)
AT 01         ?? "Page: "+LTRIM(STR(T_PRINT))     AT 150
        ?  "                                        DATE IN "   AT 01
        ?  "NAME                 HOME TOWN          COLLEGE "  AT 01
        ?? "____________________ ___________________ ______ "  AT 01
        IF .NOT. T_FIRST THEN
            _PLINENO=0
        ENDIF
    ENDIF

    ? LEFT(NAME,20)           AT 01     STYLE 'B'
    ?? LEFT(HOME_TOWN,20)     AT 22     STYLE 'I'
    ?? DATEINCOLL             AT 42
    SKIP
ENDDO

=PDDOCEND()
_PDSETUP=""
SET DEVICE TO SCREEN
SET PRINTER TO
SET PRINTER OFF
SET CONSOLE ON

Msg#:  28248   Date:  26-Jun-91
Fm: Jackie Jaynes [Sysop] 76177,2777
To: All

RE:     RQBE & Printer Setups

This note explains how printers setups work with RQBE and with reports
in general.

Only one printer setup can be active at a time.  For instance, you
might specify a printer setup using the 'Printer Setup' menu option on
the File menu.  Or you might specify:

        _PDSETUP = "mysetup"

in a program.

Now report and label forms always have a printer setup specified with
them.  If you haven't explicitly specified one, then the printer setup
specified is "<none>", i.e. no printer setup.

If you include the keyword "PDSETUP" with a REPORT FORM or LABEL FORM
command, the printer setup specified in the form is loaded prior to
printing the report or labels.  If PDSETUP is specified and the
printer setup in the form is "<none>", then any pre-existing printer
setup is unloaded prior to printing.

If you do NOT include PDSETUP with REPORT FORM or LABEL FORM, then the
report or label printing is done using whatever the current printer
setup may be at the time the command is executed.

Now the mysterious

        [ ] Printer Driver Setup

checkbox in the '[ ] Options...' dialog of RQBE, controls whether or
not the REPORT/LABEL FORM command issued by RQBE will include the
PDSETUP keyword.

We agree that the text chosen for this checkbox renders its meaning
somewhat inobvious.  In the next RC, you'll see that this text has
been changed to read:

        [ ] Use Printer Setup
            in Report/Label Form

which should make things clearer.


The text of this message has been uploaded to Library 2 in a file
called PRINTSET.TXT.

Msg#:  26317   Date:  19-Jun-91
Fm: Glenn Hart 76703,4226
To: Paul Rosner 76046,3643

I don't recall the earlier messages, but I'll try to help. Create a
printer setup by selecting Printer setup... under File. Create a new
setup, selecting your printer and the other options in the dialog.
Give the setup a name and save. You can specify this (or any other)
setup as the default if you wish, or you can click Set to put one in
effect immediately.

Anyway, once the setup is in place try

       SET PRINTER ON
       ? 'This should be boldface' STYLE 'B'
       ? 'This should be italics' STYLE 'I'
       SET PRINTER OFF
       EJECT

and see what you get!

There's more to this, in terms of wonderful flexibility, but perhaps
this will at least get you started.

       Glenn

Msg#:  18355   Date:  18-May-91
Fm: Janet Walker [Fox] 76702,1311
To: Pat Adams 75146,3121 (X)

The short answer to your comments on our printer driver speed is to
use the C language versions of said drivers (the C-language Postscript
driver will ship with RC1).  However, your remarks do suggest that an
explanation of our philosophy on printer drivers might be helpful.

Whatever the merits of our approach to printer drivers, it was surely
neither conceived nor implemented in haste.  Printer driver support
has been given careful thought and has been under development for
quite some time.

Here's my main point: FoxPro printer driver support does NOT consist
of the particular example drivers provided.  Rather, it's the basic
capability to cause procedures written either in X-base, C, or
assembler to be triggered by events associated with printing, i.e. to
be executed upon events like loading a driver, start of document,
start of page, begin/end line, etc.

Of course, the sample printer drivers DO provide basic functionality
which can be utilized by beginners and developers alike.  Moreover,
the execution speed of the C versions is perfectly acceptable.

Incidentally, the release version of FoxPro will include  X-base and C
versions of the following sample drivers (the X-base versions are
provided solely for illustrative purposes):

    General    -    based on Pete Olympia's public domain
                    database of control codes, thus providing
                    basic support for 102 printers.
    Epson      -    provided only to illustrate how a simple driver
                    is written.
    LaserJet   -    provided because programming a LaserJet is
                    complicated and hardly generic.
    Postscript -    by popular demand

However, our MAIN design objective was to make it possible for
developers and third-party utility providers to design and implement
drivers and driver utilities for any conceivable type of printer.
That is, we wanted COMPLETE flexibility and a totally open
architecture for our driver methodology.  This goal has largely been
attained.
The parameters, style clauses, etc. passed to a printer driver are
simply data input to the driver.  The meaning of a particular style
code, the action to be taken upon starting a page, what happens at the
end of a document, etc. may be any conceivable action
expressable in X-base, C, or assembler.  You can freely invent your
own style codes or redefine standard style codes.  And style codes can
trigger any activity that's possible to program.

This means, that sufficient flexibility has been provided to make it
possible for others to to implement very elaborate drivers which
support proportional fonts, generate tables, incorporate graphics,
etc.  Since C or assembler can be utilized, performance will not be a
problem (though the volume of output codes can be substantial,
particularly in Postscript, and it naturally takes more time to
transmit more data to the printer).

I hope this helps to clarify matters.

Msg#:  19275   Date:  21-May-91
Fm: Cathy Corey [Sysop] 76177,3002
To: Glenn Hart 76703,4226 (X)

Glenn,

In the next patch you can use the following command to set your
default pdriver within your config.fp file.  The dialog will not be
displayed when entering FoxPro.

     PDRIVER = DRIVER WITH "DEFAULT"

Cathy

Msg#:  31377   Date:  09-Jul-91
Fm: Lisa Slater 72077,2417
To: Y. Alan Griver 71541,3150 (X)

YAG,

You've probably already thought of this, but if they don't give us the
NODRIVER keyword, how about:

  USE the_frx
  save and remove the pdriver info  && alternatively COPY TO a
tempfile   USE                               && with no pdriver info,
& run
  run the report to the file        && that report to a file instead
MODI COMM
  USE the_frx
  put the pdriver info back
  USE

"After all, they are only databases" <G>...

>L<


Msg#:  31435   Date:  09-Jul-91
Fm: Y. Alan Griver 71541,3150
To: Lisa Slater 72077,2417 (X)

That's an interesting idea - but means that we need two of each report
(if we save them with the project).  Not a bad kludge though... <g -
"start your kludging">

yag


Msg#:  31468   Date:  10-Jul-91
Fm: Lisa Slater 72077,2417
To: Y. Alan Griver 71541,3150 (X)

No, you don't need two copies of all the reports if you USE the
read-only one and copy it TO a temp one that gets overwritten all the
time.

I don't get something, though.

What's so terrible about saving the contents of the system variable,
set it to "", run the report to a file, MODI COMM, and restore the
user's pdriver setup? I see that your original message objected to
doing it this way, but I'm not sure why it's a problem.

I must be thinking about this all backwards; help me out, here...

>L<


Msg#:  31508   Date:  10-Jul-91
Fm: Y. Alan Griver 71541,3150
To: Lisa Slater 72077,2417 (X)

The last time I tested it, it took some time setting and resetting the
variable (as Fox did their internal stuff).  I put it to the side till
the last thing - and we're getting to the last thing... <g>

Letcha know what I find out.

Thanks,

yag


Msg#:  31553   Date:  10-Jul-91
Fm: Lisa Slater 72077,2417
To: Y. Alan Griver 71541,3150 (X)

I have another alternative that I use that we could talk about if you
like, but I'd assume that USing the report form and changing that item
would take a little time also (with or without that COPY TO a
tempfile).

The fact is that running the report to a file -- even to a ram disk --
and then issuing the MODI COMM *already* takes some time, especially
compared to the PREVIEW option. We're willing to do it because of the
benefits involved, and I'm not sure that this slightly-added-time is a
problem, with that perspective.

>L<



******** THD201.DBF ********
Msg#:  130970   Date:  09-Aug-91
Fm: Toni Taylor [Fox] 76702,1237
To: Jim Blackston 75130,27

Jim,

The reason that you are not seeing the BOX characters is because the
graphics character set is not selected on your printer.  To change
this through the printer driver, do the following:

-OPEN the printer driver project
-- \Goodies\Pdrivers\genpd.pjx
-OPEN the P_Codes.dbf
-Select the HP/500 II driver
-Change the P_Setup field from <-E to <-E<-(10U.
-Build Project with the Build Application box checked.

Toni-

Msg#:  137586   Date:  22-Aug-91
Fm: Toni Taylor [Fox] 76702,1237
To: Fred Anstine 72057,1736 (X)

Fred,

Glenn is correct.  I need to know if you included GENPD.APP in your
Project. This is necessary in order to use the printer drivers in a
stand-alone .exe file.

Toni-

Msg#:  137621   Date:  22-Aug-91
Fm: Fred Anstine 72057,1736
To: Glenn Hart <Sysop> 76703,4226 (X)

Glenn,

I included it in the project file, but as an app file, it is
automatically excluded (as is the convert.app file) and cannot be
<Included>.  Therefore I have identified it in the project file but am
placing it in the subdirectory along with the dbf & cdx files I am
useing.     --Fred--


Msg#:  129076   Date:  06-Aug-91
Fm: Toni Taylor [Fox] 76702,1237
To: Abramson, P. J. 72567,3422 (X)

Peter,

We are not sure when the patches for the Distribution Kit will be
available. If you are using API routines or LOAD/CALL in your
application, you will need PROAPI16.EXE present in your created .exe
files.  One thing to remember is that the printer drivers use the API.

Toni-

Msg#:  139105   Date:  26-Aug-91
Fm: Toni Taylor [Fox] 76702,1237
To: THOMAS HAMLETT 72070,2154 (X)

Thomas,

There is not a printer driver available for the HP LaserJet III.  We
are working on this driver.  You can use the HP II driver, however,
the box characters are graphic characters and you need to set the
printer to accept graphics characters.  You can do this as follows:

1)  Select OPEN from the File pad.
2)  Change type to PROJECT and select
    Goodies\Pdrivers\Genpd.pjx.
3)  Once the project is open select the P_codes.dbf and browse
    it.
4)  Select the driver for example, HP Laser 500/II and then
    change the code from
E to
E
(10U under the P_setup field.
5)  Select BUILD PROJECT and mark an X under Build
    Application, save the file in the C:\FOXPRO2 directory.

Toni-

Msg#:  139374   Date:  26-Aug-91
Fm: Glenn Hart <Sysop> 76703,4226
To: Toni Taylor [Fox] 76702,1237 (X)

Toni,

I can't recall whether the messages were public or private, but a
couple of people reported negative results with putting the symbol set
change command in P_CODES that way. These involved non-HP laser
printers with HP PCL emulation rather than the real thing.

I agree that putting the codes in *should* work, but I personally
still prefer changing the defaults at the front panel, so screen
dumps, directory utilities and other software will use the line
drawing character set too.

       Glenn

Msg#:  124887   Date:  30-Jul-91
Fm: Walt Kennamer--Fox 74025,514
To: tom meeks 70304,2176 (X)

The database is not actually a part of the printer driver system per
se, but is included in case there is an unusual printer in it that you
need to work with.  You can use the codes in the database to define a
new printer type.


Msg#:  124967   Date:  30-Jul-91
Fm: Glenn Hart <Sysop> 76703,4226
To: tom meeks 70304,2176 (X)

Sure. The printer codes in P_CODES.DBF are read into the driver when
it's regenned.

       Glenn

Msg#:  125445   Date:  31-Jul-91
Fm: Randy Brown 71141,3014
To: Barry Schlossberg, M.D. 72155,774 (X)

Barry,

I have been using several IIPs and have also experienced problems. The
HP drivers were really written for the standard LaserJets. The main
problem is that I can't control job size (i.e., legal or letter).
Since the printer has multiple trays, I would like to have control
over this. The RQBE page eject thing is a problem and I think it
relates to the dilemma I was facing with the job size.

The solution I found was to rewrite the GENPD.APP. It is a quick fix
and only involves adding a few records to the P_Codes database. Copy
the standard record again and just modify the 5th field which controls
number of lines. In this field place a Job Size Code such as 2A or 3A.
Then rename the description, For example, I place a ...2A and renamed
this record HP IIP Letter. The 3A is for legal. You will have much
better luck using these for the IIP printer.

I still have a mysterious problem with the 'Printer not ready' error
dialog showing up right in the middle of a job even though nothing is
wrong???
Randy

Msg#:  119478   Date:  19-Jul-91
Fm: Vicki Miles 76376,63
To: all

When I try and set up a printer driver, when I push <<SET>>, I get a
message to the effect that the "Source" cannot be loaded.  The box
says proapi16.exe can't be found.  The foxpro2 directory is in my path
and in fact, it won't load even if the foxpro2 directory is the
default directory (where I started fox from).  Help???????????

Vic

Msg#:  119593   Date:  19-Jul-91
Fm: John Fitzsimmons 71041,3003
To: Vicki Miles 76376,63 (X)

Vicki,

 FWIW, the PROAPI16.EXE file must be in the SAME directory that
FOXPROX or FOXPROLX resides; not just in a directory contained in the
path.

John


Msg#:  119665   Date:  19-Jul-91
Fm: Joe Gotthelf 74017,3670
To: John Fitzsimmons 71041,3003

Also, if you have DOSMEM=something besides off, there might not be
enough memory available.  If PROAPI16.exe is in the Foxpro2 direcoty
(or wherever you put Foxpro), and you have DOSMEM=OFF in the CONFIG.FP
it will work.


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

Jim,

Below is an example for printing using '?' and the printer drivers.
I hope you will find it useful.

SET TALK OFF
SET PDSETUP TO "<your_setup>"
SET LIBRARY TO GOODIES\PDRIVERS\DRIVER2.PLB
SET PRINT ON
? PDDOCST(<page_length>,<page_width>)
? "Strings to be printed"
? PDDOCEND()
SET PRINT OFF

This example, along with your ON PAGE ? "Page Header", should print
the report exactly like you want it.

Toni-

Msg#:  138684   Date:  25-Aug-91
Fm: Glenn Hart <Sysop> 76703,4226
To: Chip Doolittle 73347,2775 (X)

THere's a separate booklet included with the documentation on the
printer drivers. It explains what PDPARMS is and what the default
elements mean. Note that these are indeed defaults basedon the SAMPLE
printer driver; some folks haven't yet grasped that the printer driver
can readily be modified, new array elements added, etc.

Personally, I just run reports one way or the other (80 vs. 132
columns, say), and create printer setups for the differences. In other
words, I don't mix fonts and sizes within one report. While I've seen
various approaches to doing this with FP, even in 1.02 prior to the
printer driver scheme, the line orientation of the report writer isn't
particularly inclined this way (for example, using a mixture of big
and tiny fonts will almost assuredly require playing with the page
length via experimentation). The printer drivers do a fine job of what
they set out to do, but I think there's plenty of room for enhancement
down the road or third-party add-ons in this area.

       Glenn


Msg#:  32862   Date:  16-Jul-91
Fm: Cathy Corey [Sysop] 76177,3002
To: Mary Clifton 71240,3523 (X)

Mary,

The printer drivers do not currently support the @ SAY command.  You
will need to use the report writer or the ? command.  If you do use
the ? command, you will need to call PDDOCST and PDDOCEND.  You may
want to look at the examples that I sent to Peter Muller regarding
PDDOCST and PDDOCEND.

Cathy


Msg#:  36193   Date:  04-Aug-91
Fm: William Salmonsen 70242,2212
To: sysop (X)

 I am still playing with the printer drivers.  The plot thickens!

 I thought I would try to REINDEX the P_CODE.DBF even I know a
 .CDX index should be maintained automatically.

 I indexed the file and looked at the Printer Driver list again.
 The printers I added were there.  I closed P_CODE.DBF and looked
 again and the printers were not there.

 Is the ARRAY saved and recalled rather than rebuild each time?
 BTW the Printer Driver Manual has an error in the table on Page
 4.  There is no P_CODES.FPT file and it is not a Memo file.
 There is however, a P_CODES.CDX Index file in the release
 version.

 I FINALLY GOT IT!!  I regenerated the GENPD.APP application and
 there they are, the printers I added.  The array is in the .APP.

 I still don't think the manual explains (Page 8 2nd paragraph)
 how to add another record to the P_CODES database.  The
 explanation on Page 9 & 10 simply tells how to change the print
 attributes.  It does not tell how to add a new model of printer
 to the database.  I strongly believe some details on how to add a
new record for a new printer to the printer driver list (not just  how
to select different features) should to be included in the
 documentation.

 I also don't think it should be necessary to regenerate the
 GENPD.APP application to merely add another printer!!  New
 printers should appear in the list as they are added.  An option
 to add new printers (if only a browse window) and edit the
 feature codes is needed!

 I thought I knew the difference between the initialization and
 reset fields.  However, the codes that the printer manuals say
 are Reset codes are in the Initialization field.  Why aren't the
 reset codes in the reset field?  How does the way the printer
 driver uses the Initialization field differ from the way it uses
 the Reset field?

Msg#:  36204   Date:  04-Aug-91
Fm: Glenn Hart 76703,4226
To: William Salmonsen 70242,2212 (X)

I've been through the same process. I too sorted it on P_NAME, but
note that a structural index (INDEX ON P_NAME TAG P_NAME) seems to be
called for. Perhaps you forgot to build the index? As you've found,
you do need to rebuild the APP, since the values in P_CODES are
included in the APP. Did you also remember to place the rebuilt APP in
the FOXPRO2 subdirectory, another potential gotcha; you might
inadvertantly be running the older, unmodified one.

In any case, the printers I've added do show up in the available
printer list and I routinely use them in printer setups with
everything working correctly.
       GLenn


******** THD202.DBF ********
Msg#:  151717   Date:  21-Sep-91
Fm: Lisa Slater 72077,2417
To: Hal Harkness 73557,2161

Certainly. I understand what you are saying.  I am asking you to

? _PDPARMS(1)

-- please notice the underscore in the array name -- *after* you have
done the configuring.  I would like to confirm that the configuring
has actually "registered".  I hope I am not offending you by saying
this -- there are a lot of confirming keystrokes in there, and a lot
of times people think they have loaded the driver but it's not
actually there.

If your driver is Postscript, _PDPARMS()'s first element will be .T.
If it is *not* Postscript, _PDPARMS will either have been released (if
no driver is loaded), in which case you'll get an error, or the first
element will be a character expression, the name of a printer.

On the other side of the equation, once we have determined for a fact
that the postscript driver is loaded, I have to ask you again to tell
me exactly what steps you used in printing the test ascii file and the
test report.  It is possible for the driver to be loaded *and yet not
used* when FoxPro accesses the printer.  For example, if you use the
PDSETUP keyword on a report, this will supersede the driver currently
loaded with the driver setup saved with the report.  The driver saved
with the report may be none at all, or a different one.  If you have
been using the PDSETUP keyword on your report, do this for me:

    USE the_rpt.FRX
    LOCATE FOR objtype = 21
    MODI MEMO name

.. what is contained in this field?

Similar problems can exist with printing an ascii file, depending on
how you chose to do it.  I am not saying you did anything wrong, just
that there are a lot of factors we should check <s>.  I hope I'm
clarifying, rather than muddying the waters, a little by amplifying
what I said before.

>L<
Msg#:  163125   Date:  17-Oct-91
Fm: Menachem  Bazian 76366,42
To: allan pulvermacher 72301,3141 (X)

Allan

re: #1, you can do download a font while the report is running. I
showed a routine to do just that at DevCon. It will be in the
supplement diskette.
The key is making the printer driver intelligent enough to know:

A> When a new font is needed, and B> When a font has to be downloaded
The idea is to create a new style code to designate a font change. If
the font has not been downloaded (I keep track of that with a
database) I download it right then and there. Works pretty nicely. and
would be not be excessively difficult to encorporate into DRIVER.PRG.

Menachem


Msg#:  152894   Date:  24-Sep-91
Fm: Jackie Jaynes [Fox] 76177,2777
To: Hank Fay 73210,1552 (X)

Hank,

In 25 words or less, PROAPI16.EXE allows 16 bit addressing mode to
access 32 bit addressing mode.   How's that?<g>


Jackie


Msg#:  147677   Date:  12-Sep-91
Fm: Cathy Selhorst [Fox] 76177,3002
To: Dave Streit 76067,1265 (X)

Dave,

The following is an explanation of what needs to be done in order to
include printer drivers in a standalone EXE:

1.  Include in your project the following:
    a. Any supporting files you need for your application.
    b. GENPD.APP (this is needed in order to tell FoxPro what else it
needs to include in the EXE that the printer drivers use and your
application doesn't.)  This will be excluded automatically.
    c. Your resource file with the printer driver setups to be
       used. (Foxuser) - included or excluded.

2.  Include in the directory where the standalone EXE is located, the
following:
    a. PROAPI16.EXE (ONLY if you are building a Standalone Extended
EXE).     b. GENPD.APP
    c. Your resource file (Foxuser) - if it was excluded in the
project.
I hope this helps.  Let me know if you have any questions.

Cathy

Msg#:  149839   Date:  17-Sep-91
Fm: John M. Miller 74176,200
To: Lisa Slater 72077,2417


<g> Alas, some of us are chosen to carry heavier burdens than others.
Your approach sounds fine to me.  I'm not expecting any miracles or
revelations from Devcon.  More like hints and suggestions. <g>

What do you think of this:

* Copy a printer setup from the printer setup resource file into the
users * resource file.  The printer setup is for any printer with the
desired * output parameters.
USE <pdsetup resource file>
LOCATE <a generic printer setup, reguardless of printer>
SCATTER MEMO
USE <users resource file>
LOCATE <default printer setup>
GATHER MEMO

* Load the default setup
REPLACE data WITH SUBSTR(data,3)             && Get rid of version
number. RESTORE FROM MEMO data ADDITIVE
REPLACE data WITH CHR(0) + CHR(2) + data

* Change the printer
g_pddriver=PADR(<<name of the output printer>>,30)

* Save the printer setup
SAVE TO MEMO data ALL LIKE g_pd*
REPLACE data WITH CHR(0) + CHR(2) + data
REPLACE ckval WITH VAL(SYS(2007,data))

* Activate the printer setup
_PDSETUP=<default printer setup>

The _PDPARMS array is now loaded with information from p_codes
database for the desired printer not the printer saved in the printer
setup resource file.

jMM

Msg#:  143320   Date:  04-Sep-91
Fm: Lisa Slater 72077,2417
To: Bob Velke 76366,1760

OK, Bob.  I see your problem now.

The ? command responds to *styles*, but doesn't activate the document
start/stop codes.  I think this is the way it's supposed to work.
Try

? "something" STYLE "B"  && should be bold

and try setting up styles from within the report writer -- anything --
too. If you don't want to waste paper, do a REPORT FORM x TO file.txt
(no PDSETUP, please) while the printer driver is loaded.  You should
be able to examine file.txt for the codes.  They will be there.

Try a DISPLAY MEMO to the printer, and you'll see it will be
compressed. (DISPLAY MEMO *does* activate the start/stop doc printer
stuff.)

You *could* use your compressed setup and do this before you start the
?'s and after the driver is loaded:

??? _PDPARMS(8)  && this is the char per inch code for the driver,
&& which you have set to compressed now;
                 && the _PDPARMS elements are all documented in
GEN_PD.PRG *
do your ?'s here

BUT if all you want is to compress stuff and use ?'s, I wouldn't use a
special driver setup for this, Bob, instead, I'd do this, with a
*regular* 10-char-per-inch driver for this printer loaded:

??? _PDPARMS(9)  && the compressed pitch entry

* do ?'s here, complete with STYLE clauses as necessary

??? _PDPARMS(8)  && set back to normal char per inch

Is this starting to make sense?

>L<

Msg#:  143651   Date:  04-Sep-91
Fm: Lisa Slater 72077,2417
To: Bob Velke 76366,1760 (X)

You don't need to check it out with the RW, that was just an alternate
suggestion so we could make sure your pdriver was "in there".

12 cpi:  No problem.  You *could* create different pdsetups for each
cpi and just switch between them. I was just suggesting that this was
not optimal if all you wanted was compressed (ie why create more
pdsetups than you really need?).

If you set up the different pdsetups, you would still ??? items from
your _PDPARMS array as required. What you are gaining here is the
ability to say something like this before you start output:

DO pset WITH "12 cpi"

Pset checks to see what's the name of the current driver in _PDSETUP.
If it can't find "12 cpi" in it, (you're going to name your printer
setups consistently), it parses out the name of the printer from
_PDSETUP and adds " 12 cpi" to get the new name of the _PDSETUP.
(Notice you don't need to know the current printer.) It SETs the
driver up and uses _PDPARMS, which is now filled with appropriate
values, to do whatever you want.

I guess you could check for postscript first off in Pset.  If you
DO pset WITH "postscript", "times", "whatever"

and Pset sees PARAMETERS()>1, it goes into an alternate route of use
for the rest of the passed string and _PDPARMS.  There would be a lot
of ways to handle this.

I'm sorry my earlier message was a little dense/terse, Bob. I don't
like it when you have to read things 8 times <s>.  But I'm afraid this
one will be just as bad, or worse, because I'm thinking out loud.
What do you think of the scenario, anyway?

>L<
Msg#:  161146   Date:  13-Oct-91
Fm: Larry Keyes 75170,64
To: Menachem Bazian 76366,42 (X)

Quick question:  I want to manual feed envelopes to my LaseJet
printer, and then have a label directly on the envelope.   I've been
fooling around for a couple of hours with the printer drivers, etc.
but I can't seem to get the code for "Feed an envelope" in the right
spot in the print stream. (I tried modifying the LaserJet+/II driver
for the LaserJet III.

I don't care about fonts (yet..<g>) but would like to print a quick
envelope for an invoice.

Is there a quick way to do this?  -- thanks  Larry Keyes

Msg#:  161509   Date:  14-Oct-91
Fm: Jackie Jaynes [Fox] 76177,2777
To: Larry Keyes 75170,64 (X)

Larry,

Put the codes in PDDOCST.  Use a procedure like the following:

 PARAMETERS chchars
 Chchars=chchars + " your codes "
 return chchars


Jackie
Msg#:  152376   Date:  23-Sep-91
Fm: Cathy Selhorst [Fox] 76177,3002
To: Lisa Slater 72077,2417 (X)

Lisa,

This is a documentation error.  The contents of _PDPARMS is displayed
when you DISPLAY MEMORY.  _PDPARMS is not displayed if SET PRINT is ON
or if you DISPLAY MEMORY TO PRINT.

Cathy
Msg#:  156208   Date:  01-Oct-91
Fm: Cathy Selhorst [Fox] 76177,3002
To: Nelson Ramos 76376,3356

Nelson,

The system memory variables can be changed just like any other memory
variable.

No the Start Document does not replace the PDDOCST procedure.  You can
modify what is sent to the printer by controlling what is returned
from the procedure.  This can be a null string (which deletes what the
PDDOCST procedure would have sent to the printer).

The system memory variables do not override the pcodes.dbf.  _PLENGTH
is sent as a parameter to the printer driver PDDOCST procedure when
you use the commands, TYPE TO PRINT or DISPLAY TO PRINT.

The error is returned because _PPITCH must be set to the values pica,
elite, condensed or default.

Cathy

Msg#:  145971   Date:  09-Sep-91
Fm: Cathy Selhorst [Fox] 76177,3002
To: Ron Parker 72341,3241 (X)

Ron,

When the printer driver is loaded the contents of _pdparms is copied
into the Printer Driver API routine.  The values copied to the routine
are used to print your report.  Therefore, changes made to _pdparms
after the printer driver has been loaded are not recognized.  The
values are loaded into the API routine for two reasons, for efficiency
and for safety purposes.  If you would like to change the values, we
would recommend doing this within the database itself.  You can also
use the XBase version of the printer drivers which always use the
_pdparms array.  I hope this helps.

Cathy

Msg#:  146910   Date:  11-Sep-91
Fm: Ron Parker 72341,3241
To: Lisa Slater 72077,2417

>> why need to tinker with _pdparms[] prior to REPORT FORM XXX

Am printing predefined form overlays on an HPLJ where the form is
downloaded into the HPLJ as a macro.  DRIVER2.PLB and DRIVER.PRG build
a document starting string having the reset (^E) as the first
characters of the string. This wipes out the macro in the HPLJ, unless
I define it as a permanent macro - which I don't want to do.

If I delete the reset I must also position the HPLJ printer cursor to
the top of the page to get the right line arrangement on the first
page.  This means adding a vertical cursor postioning sequence (^&aR)
to _pdparms[40].
The above requires a modified doc. starting string.  One solution is
to create a tailored driver in P_codes.dbf but this 'hides' the
solution and modifies a system file - techniques I try to avoid.

My preferred solution is to modify _pdparms after issuing the SET
PDSETUP TO 'XXX' (e.g. _pdparms[3] = '') and before the REPORT FORM
YYY ...

Using DRIVER.PRG instead of DRIVER2.PLB allows me to do the mods my
way.
Probably more than you wanted to know, but there it is, R.

Msg#:  147075   Date:  11-Sep-91
Fm: Cathy Selhorst [Fox] 76177,3002
To: Ron Parker

Ron,

Now that you have described exactly why you wanted to change _pdparms
we have another method you may want to try.  You could also append a
record to the database that contains the same contents as the printer
driver that you normally use and replace the setup codes with whatever
you assigned _pdparms to.  The reason we suggest this is because it
will be faster.

Cathy



******** THD203.DBF ********
Msg#:  172742   Date:  04-Nov-91
Fm: John M. Miller 74176,200
To: Lisa Slater 72077,2417


>L<,

I've discovered by examining DRIVER.PRG from GENPD project that if you
include a {#B} in the p_flen field of the pcodes database that the
driver will substitute an ascii character of the form length
(CHR(_plength)) when setting up the document.  If you include {#} the
driver will substitute the trimmed string of the form length
(alltrim(str(_plength)).  I don't think that this is documented
anywhere.

With any luck I'll have put off having to understand print jobs and
the printer system memvars for another day. <g>

jMM


Msg#:  178095   Date:  15-Nov-91
Fm: Jackie Jaynes [Fox] 76177,2777
To: John M. Miller 74176,200 (X)

John,

We have added the {#B} and {#} codes to the P_CODES.DBF for the NEC
Pinwriter. The reason why these codes are missing from a lot of other
records is because we did not know what these codes were for these
printers. We technically only support the HP, Epson, and Postscript
printers.  If you know the codes to any of the other printer drivers,
please let us know and we will add them to the dbf.


Jackie

Msg#:  180369   Date:  20-Nov-91
Fm: Cathy Selhorst [Fox] 76177,3002
To: Tom Canning 71650,1610 (X)

When using the printer drivers with the ? command you need to call the
Pdocst and Pddocend procedures.  These procedures need to be called
because when using the question mark command, the printer drivers do
not know when the document starts or ends.  You therefore need to make
the calls for it.  The fact that these procedures are not called may
be causing the problems that you are seeing.  The following is an
example of what needs to be done.
SET TALK OFF
SET PDSETUP TO 'HP'
SET LIBRARY TO GOODIES\PDRIVERS\DRIVER2.PLB
SET PRINT TO PFILE.TXT
SET PRINT ON

?PDDOCST(_PLENGTH, _RMARGIN)

? "HI WORLD"

?PDDOCEND()

SET PRINT OFF
SET PRINT TO
SET LIBRARY TO
SET PDSETUP TO 'HP'

If you have any further questions please let me know.

Cathy


Msg#:  180868   Date:  21-Nov-91
Fm: Cathy Selhorst [Fox] 76177,3002
To: Jim Slater 76367,1735 (X)

Jim,

Currently EJECT PAGE is not supported by printer drivers.  We are
looking into what this would affect if this support were added.  In
your example the reason you are seeing extra form feeds is because you
are telling the printer drivers that your form length is 66.  This is
done in this statement,
?PDDOCST(_PLENGTH,_RMARGIN), given that you have not changed _PLENGTH
from it's default.

Cathy

Msg#:  176670   Date:  12-Nov-91
Fm: Chaim Caron 72520,2272
To: Robert Dobson 100012,3362 (X)

Robert,
  Regarding setting the printer to another symbol set: you must
specify a user procedure for document start.  You do this for each
printer driver setup you will use for the printer.  If your printer is
an HP LJ II or III, you can use this user procedure:

 PROCEDURE pdsdcrm8
 PARAMETER lcInParm
   lcInParm = lcInParm + CHR(27) + '(8U'
 RETURN

  Regards, Chaim


Msg#:  176398   Date:  12-Nov-91
Fm: Chaim Caron 72520,2272
To: All

  I am creating a custom printer driver and have some questions about
how to include it in the project.  I am running the base product.

  1.  I am currently referencing the printer driver successfully by
making an explicit full path reference to it in _genpd as follows:
  _GENPD = 'C:\subidr\appname.app'

  2. If I wanted to include the printer driver in the project, would
it still be necessary to set _GENPD explicitly?
  3. Would the answer to 2. be different if I were creating a runtime
module instead of an app that runs with the base product?
  Thanks, Chaim



Msg#:  177102   Date:  13-Nov-91
Fm: Cathy Selhorst [Fox] 76177,3002
To: Chaim Caron 72520,2272 (X)

Chaim,

Yes you will need to set _GENPD explicitly.  This is because the value
of _GENPD is executed.  If we cannot find the file, an error will be
returned.
Cathy


Msg#:  183425   Date:  27-Nov-91
Fm: Lisa Slater 72077,2417
To: David M Rogge 100034,1071

Your printer driver setup is not "taking" for some reason.  Do you
have GENPD.APP added to your project?  Do you have GENPD.APP also
available as a separate file in the same directory with your EXE?
(You also need to have PROAPI16.EXE in that directory.)

Additionally, does the resource file used by the EXE (whether bound
into the app or otherwise) have your PS printer driver setup as a
record in it?
How did you find out about the output?  Presumably your PS printer
wouldn't be printing anything... are you printing to a file first?

Put the following in your code after the SET PDSETUP TO "My PS Setup"
or whatever line you use to choose the pdriver setup, as a procedure.
      PROCEDURE pdsetchk
      SET PRINTER TO pd_test.txt
      SET PRINTER ON
      SET CONSOLE OFF
      ? "setup         = "+_PDSETUP
      ? "driver        = "+_PDRIVER
      ? "PD app        = "+_GENPD
      ? "_PDPARMS(1)   = "
      IF TYPE("_PDPARMS(1)") # "U"
         ?? _PDPARMS(1)         && would be .T. or .F. for PS setup;
                                && won't exist for no setup, will be
                                && a char printer name for non-PS
setup
      ENDIF
      ? "resource file = "+SET("RESOURCE",1)
      ? "resource is set:"+SET("RESOURCE")
      ? "config.fp file :"+SYS(2019)
      ? "FP directory   :"+SYS(2004)
      ? "curr directory :"+SET("DEFAULT",1)+SYS(2003)
      ? "PD app is here :"
      ?? SYS(2003) $ _GENPD
      ? "PROAPI16 here  :"
      ?? FILE("PROAPI16.EXE")
      ?
      SET PRINTER TO
      SET PRINTER OFF
      SET CONSOLE ON
      MODI FILE pd_test.txt NOMODIFY
      * of course it will look really funny if you *really*
      * have the PS driver set up... <g>
      RETURN

.. I just made this up <g>, but I think it's a fairly complete test.
Let me know what you see, okay?

>L<


Msg#:  179502   Date:  19-Nov-91
Fm: Menachem  Bazian 76366,42
To: Chaim Caron 72520,2272 (X)

Chaim,

I'll answer question in order.

1. No. They do not exist because, in Fox's version, they are not
needed. I do not believe that they exist in the API version either.

The PDOBJECT procedure, which is called concurrently with the object,
performs the function of BOTH the PDOBJST and PDOBJEND procedures --
hence they are superfluous.

Take a look at PDOBJECT and you'll notice that it returns:

Starting Control Characters + Value to Print + Ending Control
Characters
2. No CHaim. What I meant was that the STYLE dialog treats them
differently. Try this and I think it will be clear. Open up a style
dialog to any object and tyoe in the letter B in the text field. BOLD
will be checked. Then put a quote " before the B and you'll the check
on BOLD disappear.

The printer driver does not recognize the ". It will ignore the
character in the PDOBJECT procedure. No, what I was referring to was a
custom designed PDOBJECT procedure.

3. To be honest I haven't looked at that. Hang on a sec while I
look... <g> I'm back. It doesn't look like they do anything with it.
The only place that it could be in is in PDOBJECT because PDOBJECT is
the onyl procedure that has the attributes passed through to it by
FoxReport.

I would be very interested in hearing how you're doing things. L-rd
knows there are several million ways to defur a feline. I am
interested in your method.

Menachem


******** THD205.DBF ********
Msg#:  202876   Date:  13-Jan-92
Fm: Lisa Slater 72077,2417
To: Randy Pearson 73020,642

Randy,

PMJI, but I've wrestled with some of the same issues that Pat has to
deal with in Pro2Er, albeit in a less all-encompassing fashion <s>,
and I wanted to share my thoughts with you on the escape sequences
written into the memofields if a pdsetup is in force.

I've made the decision to leave things like that also.  I do a LIST
STATUS and LIST MEMO... I could save the pdsetup, nuke it, and then do
the LISTs and restore it but several things would happen:

-- I am introducing more problems into a situation that has already
caused an error, if the error happened to have anything to do with the
resource file or a couple of other things;

-- I am not going to get the contents of _PDPARMS() and _PDSETUP
accurately reflected in my LISTing.  Assuredly, I could take care of
these things myself (I take care of *lots* of other things MEMO and
STATUS don't include), but it is an added hassle.

I *could* parse out the escape sequences from the resulting memofield
pretty easily, but I finally decided it might actually be interesting
to see them sometime, along with all the other junk I'm dumping in
there that may or may not be the "crucial" piece of information
someday... so what the hey <s>.
There is one possible exception to this decision that I have not taken
care of, and that I am not sure either you or Pat has considered:

If you have a postscript pdsetup in force, your LISTing might be
*really* hard to read <g>.  You can test for this easily enough (it
doesn't matter what the setup is called, you just test TYPE() for
_PDPARMS(1) -- if it's "L", you're into PS -- and I suppose I should
just do it <sigh>.

>L<

Msg#:  204854   Date:  16-Jan-92
Fm: Lisa Slater 72077,2417
To: Erik L. Rogers 70323,1673

Hello Erik,

1.) _PPITCH doesn't happen to work the default GENPD pdriver system,
which in fact ignores most of the printer system variables (which are
left over from an early, dBASE IV-compatible printer control system).
One of the reasons this is not stated clearly in the docs is that
there is absolutely no reason why you couldn't adapt GENPD to pay
attention to _PPITCH.  It would be a trivial change to make, in fact.

2.) Without changing GENPD you can add a User procedure to your
printer drivers (this would be a user proc on the doc start procedure)
using the normal GENPD dialog.  This user proc would also be trivial
to write; it would check _PPITCH and change the printer code string
that the doc start procedure sent it using the appropriate _PDPARMS()
element depending on what it found.

3.) You can get what you want without even making that change <s>.
You can write a little UDF in the first position of your reports
(title band or whatever) that checks the status of _PPITCH -- design
any system of designation you want -- and sends the appropriate
_PDPARMS() element to the printer using a ???.  Since this would occur
after the doc start procedure was sent,  it would not be countermanded
by the printer driver in any way.

Here you have three methods, all of which require you to explore a
little more about the pdrivers but certainly don't require you to do
anything "impractical" such as putting codes in for every object!  I
hesitate to recommend any one of the three above the other two,
because what appears "sensible" and easy to one person is not always
apparent to another -- but I feel sure that one of the three will work
for you and I will help you if you get stuck.  Okay?

>L<

Msg#:  200693   Date:  07-Jan-92
Fm: Randy Brown 71141,3014
To: Glenn Hart <Sysop> 76703,4226 (X)

One comment I would like to add to your nice overview of the printer
drivers. If you are going to change the GENPD.APP as I have done to
add add'l HP IIP p_code records, I would suggest creating a new name
for it such as XGENPD.APP which you can specify with the _GENPD
variable at startup or later on. Why? Whenever Fox uploads a new
patch, they usually include updated drivers and a new GENPD app which
will easily overwrite anything you may have modified.
RB

******** THD206.DBF ********
Msg#:  218700   Date:  14-Feb-92
Fm: Chuck Werner 71740,233
To: All

FYI:  While creating a series of User Procedures for use with my
printer driver, I ran into a problem that cost me 2 days to track
down.  Maybe this will help you avoid my mistake.

I initially created the user procedures *outside* my custom GENPD.APP
so that I could test them and make quick changes without having to
rebuild the APP with every change.  All files were in the default
directory so I didn't think there would be any major problems.  After
the driver was working the way I wanted, I copied my procedures to
three other computers, ensuring that all files were in the default
directory.

Everything worked fine on three of the four computers.  On the fourth,
a 386SX clone with 5MB of memory, it ran *so slow* that I at first
though it had locked up.  The only indication that anything was
happening was an almost constant series of hard disk accesses.  After
ruling out any conflict with memory or other drivers, I found the
solution:

*DON'T* put your printer driver or your user procedures *outside* the
.APP! Apparently the driver library doesn't look for the user
procedures the same way as a normal FP program.  The disk accesses
apparently were the result of the driver constantly opening and
calling the user procedures! Placing the user procedures *inside* the
.APP made them readily available and solved the problem immediately.

->ChuckMsg#:  221364   Date:  20-Feb-92
Fm: Chuck Werner 71740,233
To: Jim Thompson 71441,1760 (X)

Jim,

I'm only about three weeks ahead of you, so I'm pretty much a novice
too.  I have learned a few things about _working with_ the FP2 printer
driver, although I still don't know exactly how the darn thing works.
(It's kind of like gravity - you don't have to understand it to know
how to fall down <g>)
1)      Follow Fox's advice and don't try rewriting the actual driver
until you get a good feel for how it works.  It's a bear to try to
understand and the code in the .prg drivers is not as well commented
as the screen and menu builders.

2)      When you have something you want add to a procedure, (like
additional attributes to the PDOBJECT procedure, startup codes to the
PDDOCST procedure etc) create simple user procedures and declare these
through the GEN_PD.app.
3)      The action of these user procedures is fairly straightforward
- FP2 sends you a string as a parameter.  You just add the additional
codes to the end of the string and RETURN it at the end.  FP2 will
send it to the printer at the appropriate time.

4)      Make sure you rebuild and recompile the GEN_PD.app to
*include* any user procedures you write. It took me over a day to
diagnose this little quirk.

That will get you thinking, I hope.  With the new dot-matrix printers,
there are so many neat features you can access fairly easily through
the user procedures route.  Give it a try and let me know.

->Chuck

Msg#:  224294   Date:  26-Feb-92
Fm: Roger Ide 73307,2276
To: Matt Peirse 100033,2071

Matt,

The file you're looking for is DRIVER.PRG.  You'll find PDDOCST() in
there.  There are nine functions in DRIVER.PRG, which can pass and
receive values from functions that you write. Take a look at it, but
then try this:        Look on page 12 of "Foxpro Printer Drivers", and
then on page 14.  Page 12 has the dialog from deep inside Printer
Driver Setup - Edit, the 'User Procedures...'.That's where you need to
go.  But first, you need to create the files that you'll be entering
at that dialog, so you won't waste a lot of time.

Now look on page 14.  Here's a list of the functions in DRIVER.PRG
that you can control with your functions.  When you make a function,
be sure to include the right number of PARAMETERS, and to RETURN that
number of values.

Then you can go to Printer Driver Setup -Edit, click on "User
Procedures..." and fill in names of your functions in the proper
places. Now the driver will look to your functions for additional
printer codes at those points in the document that you have indicated.

It is important to note that you will not be able to access the 'User
Procedures..' dialog if you don't have a large array defined, because
that procedure makes its own big array, and won't start without enough
space.  So if find that option disabled, exit the setup mode and
release some memory. Then you can do it.  Better yet, release
everything before you go in.  Save some time for something else.

Look at GEN_PD.PRG for a big list of _pdparms().  Get to know this
array.  Study the examples in the Printer Driver book from DRIVER.PRG,
so that you know how the values you want to pass will be used.

Don't use the characters 'B U I C L R' to in your custom codes because
they are reserved, and study th Style Dialog in report maker to be
sure I didn't leave one out.

There's more but maybe this is enough.
       Good Luck,
               Roger

Msg#:  224964   Date:  27-Feb-92
Fm: Dave Watkins [Fox] 76004,2575
To: Matt Peirse 100033,2071 (X)             Matt,

Yes it's true that the Library must be loaded twice. The initial
Library that is loaded, is not a callable library, which means you
cannot access the functions from within a program. I believe that
there have already been requests to add this fact to the
documentation. As far as unloading .PLBs, our next release, should
have a RELEASE LIBRARY <libraryname> command which will allow you to
release individual libraries as opposed to having to release all of
them and then reload.

Glad the email helped.

DaveMsg#:  215628   Date:  09-Feb-92
Fm: Chuck Werner 71740,233
To: Lisa Slater 72077,2417

Lisa,

I received your message Friday night but I haven't had time to answer
until now.  I finally decided to set aside my attempts to rewrite the
xBase printer driver until there's a better example program to use as
a starting point. Besides, your arguments about not wanting to rewrite
the driver every time Fox upgrades its drivers were *very* persuasive.
<g>

The end result is that I've switched back to the .PLB driver.  I wrote
very basic user procedures for all the printer driver procedures, so
that I can experiment with them.  The starting point is a simple
procedure that just takes FoxPro's parameter and RETURN's it back.
Eventually, I'll eliminate the procedures that I don't use.

This technique works *very well*, I'm pleased to report <G>.  I solved
the problem of my paper advancing when I didn't want it.  Here's how:
The page advance algorithym is in the PDPAGEST user proc.  I set a
report variable named "PD_EndFlag" in all report forms that o everyone
else, but I haven't seen it elsewhere), is to remember to add a
CHR(13) to the end of the setup strings you send to a dot-matrix
printer.  Without this, the printhead moves the length of the setup
string across the paper before printing the first line of actual text.
The CHR(13) dumps the line buffer and tells the printer to start at
left margin.

BTW, I finally found a copy of your new book.  Congratulations on an
outstanding effort!  If I were to teach a class on FoxPro, this would
be a required textbook.  One comment, if you have any influence with
the publisher, suggest that they use heavier paper.  I've been
highlighting interesting sections and the ink bleeds through!


******** THD07.DBF ********

Msg#:  240590   Date:  31-Mar-92
Fm: Dave Watkins [Fox] 76004,2575
To: Bob Mavity 76106,623 (X)

Bob,

I think I know what is happening here. I don't think that the LJ3 p is
shipped with support for an 8 pt Courier fontsize. This is not a
scalable font, so when you try to put it into this mode, your printer
will try to choose the closest size it has to this. According to a
chart that I have, the only internal Courier bit map font sizes that
are shipped with the LJ3 p are a pitch of 10 and pointsize of 12, or a
pitch of 12 and a pointsize of 10. You may want to check either the
documentation, or with HP's support, to make sure.

Let me know what happens.

Dave
Msg#:  270645   Date:  06-Jun-92
Fm: Lisa Slater 72077,2417
To: Nick  Pupillo 71435,1417

<sigh>  This is not my weekend for easy solutions to pdriver
questions.
OK, here goes:

1.) Both _PDSETUP = "some name" and SET PDSETUP TO "some name" require
two work areas.

2.) If you use these commands with the View window open,
interactively, you'll see that they both properly restore you to your
original work area. I have done this with 23 workareas filled, and the
two empty ones were randomly selected, and I had no problem.

3.) However, the pdsetup *dialogs* will require a SELECT to be done --
this will mean (I believe) a total of *four* workareas opened and
used.
4.) If your named pdsetup doesn't exist in the current resource file,
GENPD will go into the pdsetup dialogs, thus requiring more workareas
than normal (IOW the four, not the two).  However, when GENPD is done,
assuming you have the requisite four workareas open, you are returned
to the appropriate work area.

I'm guessing that you are coming on a combination of factors that I
haven't tested yet.  Is your resource file:

1.) read only or built into the APP?

2.) SET OFF?

Either of these circumstances might be leading to an error I haven't
encountered yet -- should I/you test in that direction?

Alternatively, do you have as many as 24 workareas filled, which would
cause GENPD to crash -- or if your pdsetup might not be available, as
I say, it might crash with only 22 filled?

When I tried this interactively I had no ON ERROR program active.
Perhaps yours is stepping and preventing you from seeing that GENPD is
crashing in the middle (because you have no CASEs for the error #s
that occur), so that you are being left in whatever workarea GENPD
used for one of its temporary files and are unaware of what went on...

>L<

Msg#:  242936   Date:  04-Apr-92
Fm: Doug Dodge 70153,1772
To: Doug Dodge 70153,1772 (X)

Ughh..  CI$ mangled the original following messages..  Here's a
re-send.
[Continued from previous message....]

{#}       Represents a substitution that needs to be done at runtime.
This is           specific to the command and printer in which it is
found.  The
          literal {#} is substituted with the actual ASCII numeric
values.

          (example waxed by CI$)

               In the P_CODES database, the p_flen field is equal to
          [ESC]&l{#}F.  The [ESC] is actually the left arrow
character,
          CHR(27) (left arrow).  The literal {#} would be replaced at
runtime wi           actual number of lines per page of a document
which is passed in to           the PDDOCST() procedure.

               For example, if you were to send a report to a file and
the
          report was defined with 40 lines per page, you will see the
          following in the file: left arrow&l40F. The literal {#} was
replaced w           the specified number of lines per page.{#B}
Represents a BINARY substitution that needs to be done at runtime.
          This is specific to the command and printer in which it is
found.           When this substitution takes place, a binary number
is used instead           of ASCII numbers.  The {#} command, by
contrast, substitutes an
          ASCII value rather that a BINARY value as the {#B} command
does.

          (another example waxed by CI$)

               In the P_CODES database, you will see the p_flen field
is
          equal to left arrowC{#B} (Remember, 'left arrow' =
'CHR(27)').  The li           would be replaced at runtime with the
binary number of lines per
          page of a document which is passed in to the PDDOCST()
procedure. Msg#:  227258   Date:  04-Mar-92
Fm: Rick Waddell [FOX] 75300,1045
To: Mike Reed - CompuSolv 76266,3724 (X)

Mike,

Yes, the PDSETUP bug has been isolated.  Yes, this can haapen in your
own code.

If a releationship has been establish (parent to child) and no record
operation is done in the child database, it can happen. If you take a
look at what genpd.app does (you can call it yourself with the two
parameters 0, your_setup_name) you should see what will cause this.
After setting up your view, no record operations are performed on the
child database; so, the relation is set but the "filter" on the child
database doesn't get established until you manipulate the database in
some way.

In GENPD.APP it selects a new workarea and performs other database
manipulation on it's own.  When it is done, it selects the workarea
which you had selected.  Since you haven't established that "filter"
for the child database, the first time the report writer looks at the
child database, it sees that it is at EOF.  It then skips to the next
record in the parent which establishes the "filter" for the child and
off you go. Try the following:
CLEAR ALL CLEAR MEMO RESTORE FROM test SET VIEW TO test DO
\FOXPRO2\GENPD.APP WITH 0,'HP LJ II 10CPI' ?schlfile.school      <----
should print nothing

Now do the same thing with one more line.

CLEAR ALL CLEAR MEMO RESTORE FROM test SET VIEW TO test
?schlfile.school <---- This establishes the "filter". DO
\FOXPRO2\GENPD.APP WITH 0, 'HP LJ II 10CPI' ?schlfile.school   <----
This time will print out the school.

The same situation occurs when you SET VIEW TO test and immediately
BROWSE schlfile.  You will see all the records.  But once you BROWSE
the parent you will only see the "filtered" records.  Hope this helps.

Rick

Msg#:  227315   Date:  04-Mar-92
Fm: Mike Reed - CompuSolve 76266,3724
To: Rick Waddell [FOX] 75300,1045

Rick, I'm not sure I understand.

Why does REPORT FORM without PDSETUP "see" the correct child relation
yet REPORT FORM PDSETUP does not for the very 1st record?  In both
cases I *do not* move the parent record pointer at all before
executing REPORT FORM.
IOW, after I SET VIEW TO TEST, FP *does* see the proper related fields
for the current parent record *without* having to move the record
pointer.  So I've always assumed that FP set the child "filter"
immediately after issuing a SET RELATION TO command.  Running GEN_PD
seems to destroy/alter the child relation for the current parent
record.

Are you saying the bug could be described as follows:

 After initially issuing a SET RELA TO for a parent, if you SELECT
another  work area and then reSELECT parent, relations for the current
parent record  are lost ?

Assuming this is the bug, will a SKIP 0 reestablish the 1st rec's
relation ? Or do I have to do a SKIP 1, SKIP -1 or GOTO RECNO() ?
Which should be the fastest ?

Thanks, Mike
Msg#:  228528   Date:  06-Mar-92
Fm: Mike Reed - CompuSolve 76266,3724
To: Rick Waddell [FOX] 75300,1045 (X)

Rick, Thanks for the example.  So immed after setting a RELA, the rela
into a child dbf is especially vunerable if you don't "lock" into the
child (ie. ?schlfile->school), right ?

This "vunerability" is the bug you said will be fixed in next patch,
right ?
Lastly, when (approx) should we expect next patch that fixes among
other things:  (I realize we got spoiled with biweekly patches in the
begin <g>)
  a) Better performing SCATTER/GATHER (dates back to 10/91)
  b) CALL and memory var "locking" problem
  c) this RELA vunerability

As always, thanks so much for your help, Mike

Msg#:  240237   Date:  30-Mar-92
Fm: Chris Pudlicki [Fox] 76702,1237
To: Rick Evans 70521,3635 (X)

-Rick

There are two things that you can do since the printer drivers
maintain their own line count.  One, is to return any values that you
want printed to the RW so that it can print them.  The other is to
modify the GENPD code in the GENPD.PJX so that it uses something else
to do the line count.

--Chris