VFP 愛用者社區

[Ruey]

DOS has the following reserved device names:


AUX, COM1, COM2, COM3, COM4 Serial Ports (AUX is the same as COM1)
PRN, LPT1, LPT2, LPT3 Parallel Ports (PRN is the same as LPT1)
CON The Console (Screen)
NUL Null Port (Nowhere/ByteHeaven)
These device names are also reserved file names. Therefore if you execute the DOS statement

echo hello > lpt1, the word hello would appear on your printer; it would not create a filename called LPT1. The same is true if you were to re-write the statement as echo hello > e:\mydir\lpt1.dum. No file would be created on your E Drive; the output would go to the printer.

FoxPro (like any other application that uses the standard BIOS routines) will do the same thing. So the command list to file e:\mydir\lpt1.dum will list your database directly to your parallel port. You can get the same result by issuing the commands set printer to e:\mydir\lpt1.dum and then list to printer.

You'll see that FoxPro for Windows (FPW) does not always exhibit this same behaviour.



--------------------------------------------------------------------------------
pdsetup that happens to be currently active and then FPW will print the output using the currently-active Windows Printer Driver.


--------------------------------------------------------------------------------
report form windef to file destination:
Behaviour: FPW prints to the destination using the currently-active Windows Printer Driver, printing the report and all its objects as designated in the Report definition (in other words, graphical output). If the pdsetupclause is included, it is ignored. If any pdsetupis active when the command is issued, it is ignored in favor of the Windows Printer Driver.

Examples:


REPORT FORM windef TO FILE LPT3
Outputs directly to the parallel port.
REPORT FORM windef TO FILE E:\TEST\MYFILE.TXT PDSETUP
Outputs to that filename. The pdsetup clause is ignored.
Conclusions: Nothing unexpected here.


--------------------------------------------------------------------------------
windef TO PRINTER

Ignores the set printer to filename and instead prints to the default Windows Printer Driver. The active pdsetup is ignored.
Conclusions: If you want to print a Report/Label definition that contains Windows objects, then you cannot designate the destination of your output through the set printer to command. This can be overcome by using the to file clause instead or else defining all the appropriate Windows Printer Drivers you may need for output to different ports so you can select the one you want. before printing.



--------------------------------------------------------------------------------
set printer font (In other words, the output is graphically created as a rule) ELSE Print to destination in character mode ENDIF ENDIF

It is important to know that you will not see any output until you issue a set printer to command to close the print job.
It should be noted that if a pdsetup is active, then the @say command does not execute any of the PD functions (which is also true in FoxPro/DOS). The ?/?? command will execute the _pddriver's pdobject() function with whatever style clause you may have stipulated being passed as a parameter to it. The pdadvprt() may also be called by a ?/?? command (and ? will cause pdlineend() and pdlinest() to execute also).

When printing in character mode, there is some strange behaviour that goes on when you mix output using both ?/?? and @say. It seems that all of the output from the ?/?? commands get collected into a pool of some sort and the output from the @say's get collected in a separate pool. When you issue the set printer to to close the print job, the pool of ?/?? output gets spit out, followed by the pool of @say output. It seems that an attempt was made to fix this "pooling" phenomenon in version 2.5a, but it still does not act as it should, as you will see shortly.

It is interesting to note that even though this behaviour is exhibited, the ?/?? command will still update the values of prow() and pcol() correctly. Consider the following program:

SET PRINTER TO MYFILE.TXT
SET PRINTER ON
SET DEVICE TO PRINTER

?
?? "This is on row "+LTRIM(STR(PROW()))
@ 3,3 say "Row 3 Column 3"
?? " I'm on row "+LTRIM(STR(PROW()))
?
?? "Now I'm on row "+LTRIM(STR(PROW()))
@ 6,10 say "Row 6 Column 10"
?? " This is on row "+LTRIM(STR(PROW()))
?
?? "Now I'm on row "+LTRIM(STR(PROW()))
@ 8,12 say "Row 8 Column 12"

SET DEVICE TO SCREEN
SET PRINTER OFF
SET PRINTER TO
RETURN
The program will give the following (expected) output in FoxPro/DOS:

Row +---------------------------------------------
0 |
1 |This is on row 1
2 |
3 | Row 3 Column 3 I'm on row 3
4 |Now I'm on row 4
5 |
6 | Row 6 Column 10 This is on row 6
7 |Now I'm on row 7
8 | Row 8 Column 12
+---------------------------------------------
The same program run in FPW 2.5 will output the following garbage:

Row +---------------------------------------------
0 |
1 |This is on row 1 I'm on row 3
2 |Now I'm on row 4 This is on row 6
3 |Now I'm on row 7
4 |
5 | Row 3 Column 3
6 |
7 | Row 6 Column 10
8 | Row 8 Column 12
+---------------------------------------------
FPW Version 2.5a is different, but still not correct:

Row +---------------------------------------------
0 |
1 |This is on row 1 I'm on row 3
2 |
3 | Row 3 Column 3
4 |Now I'm on row 4 This is on row 6
5 |
6 | Row 6 Column 10
7 |Now I'm on row 7
8 | Row 8 Column 12
+---------------------------------------------
What a mess, huh? Actually, this can be solved by printing solely using @say statements. Just substitute all instances of "?" with @ prow() + 1, 0 say and all instances of ?? with @ prow(), pcol() say.
Conclusions: Don't mix ?/?? and @say's when printing in character mode. If you have no pdsetup active, then you can't print to a filename that starts with "PRN" or "LPT" or print directly to a parallel port.



--------------------------------------------------------------------------------
Now let's look at some examples using the above program (without @say's):

DO TESTQM3 WITH "", "LPT1", .F.
Will output the following:

+-----------------------------------------------
|
|Test Line 1 (Printed in 30-point Arial)
|Now printing a triple (Printed in raw character mode)
|Test Line 2Another triple
|Test Line 3
+-----------------------------------------------

DO TESTQM3 WITH "Epson-10cpi", "LPT1", .F.
Will output the following in character mode:

+-----------------------------------------------
|
|Test Line 1Now printing a triple
|Test Line 2Another triple
|Test Line 3
+-----------------------------------------------

DO TESTQM3 with "", "MYFILE1.TXT", .F.
DO TESTQM3 with "Epson-10cpi", "MYFILE1.TXT", .F.
Will both output the following in character mode:

+-----------------------------------------------
|Another triple
|Test Line 3
+-----------------------------------------------

DO TESTQM3 with "", "MYFILE2.TXT ADDITIVE", .F.
DO TESTQM3 with "Epson-10cpi", "MYFILE2.TXT ADDITIVE", .F.
Will both output the following in character mode:

+-----------------------------------------------
|
|Test Line 1Now printing a triple
|Test Line 2Another triple
|Test Line 3
+-----------------------------------------------
Now let's introduce some @say commands:

DO TESTQM3 WITH "", "LPT1", .T.
Will output the following:

+-----------------------------------------------
|
|Here is an @SAY in row 1 (Printed in 30-point Arial)
|Test Line 1
|Now printing a triple (Printed in raw character mode)
|Test Line 2Another triple
|Test Line 3
|
|
|
|Another @SAY in row 6
+-----------------------------------------------

DO TESTQM3 WITH "Epson-10cpi", "LPT1", .T.
Will output the following in character mode:

+-----------------------------------------------
|
|Test Line 1Now printing a triple
|Test Line 2Another triple
|Test Line 3
|
|Here is an @SAY in row 1
|Another @SAY in row 6
+-----------------------------------------------

DO TESTQM3 with "", "MYFILE3.TXT", .T.
DO TESTQM3 with "Epson-10cpi", "MYFILE3.TXT", .T.
DO TESTQM3 with "", "MYFILE4.TXT ADDITIVE", .T.
DO TESTQM3 with "Epson-10cpi", "MYFILE4.TXT ADDITIVE", .T.
Will all output the following in character mode in FPW2.5:

+-----------------------------------------------
|
|Test Line 1
|Here is an @SAY in row 1
|
|
|
|Another @SAY in row 6
+-----------------------------------------------
And will all output the following in character mode in FPW2.5a:

+-----------------------------------------------
|
|Here is an @SAY in row 1
|Test Line 1
|
|
|
|Another @SAY in row 6
+-----------------------------------------------
Conclusions: What a fiasco! The only scenario in which the ??? command works correctly in concert with both ?/?? and @say is when printing to a port (rather than a file) using a pdsetup. However, since printing using a pdsetup is in character mode, the ?/?? and @say's do not print correctly in reference to each other (see ?/?? and @say in this document). The ??? command does work correctly with the ?/?? command alone in the scenario where you print to a File in additive mode or when you print to a port with a pdsetup. Bottom line: It looks like FPW treats the ??? command as a purely DOS feature.


--------------------------------------------------------------------------------
, the eject command essentially just does a ? chr(12). Everything works fine with eject when running under a Windows Printer Driver. However, when you have a DOS pdsetup active and an eject executed just prior to closing your print job, it gets lost. Actually, it seems to sit around in an internal buffer somewhere and gets output next time you start a new print job. Consider the following:

_PADVANCE="FORMFEED"
SET PDSETUP TO "Epson-10cpi"
SET PRINTER TO MYFILE1.TXT
EJECT
SET PRINTER TO
After executing the above, myfile1.txt is empty. Now do the following:

SET PRINTER TO MYFILE2.TXT
SET PRINTER ON
?
SET PRINTER OFF
SET PRINTER TO
Now myfile2.txt contains a formfeed, followed by the carriage return and line feed created by the ? command.
If you do an eject, it may be a good idea to execute the command ?? "" immediately afterwards. This will force the form feed character to be output.

Since eject does a ? chr(12), you shouldn't mix it with @say commands if you are printing in character mode, because of the strange behaviour exhibited by mixing ?/?? and @say commands. What happens is that all the formfeed characters get printed first and then all the @say's. I suggest you use a @ 0, 0 in place of an eject when doing @say output.

When _padvance="linefeeds", then all bets are off if you are printing in character mode. There have been times when I've executed the following statements 10 times in a row and gotten 10 different sets of file contents:


_PADVANCE="LINEFEEDS"
SET PDSETUP TO ""
SET PRINTER TO MYFILE.TXT
EJECT
SET PRINTER TO
It seems that sometimes the print job closes too fast for all the linefeeds to get into the file.


--------------------------------------------------------------------------------
to your printer in FP/DOS and then look at the value of pcol() it will happily give you a value of 200, even though your printer overflowed the output onto 2 or more lines. In FPW, on the other hand, pcol() will give you the actual print head column position. The same is true with prow(). If you output 100-or-so ? commands to your printer in FPD, it doesn't know that you've overflowed onto a new page, but FPW does and the prow() will accurately reflect the row position on the new page. Not only will pcol() and prow() return true values, but they can be translated into different font measurements as well. Try the following:

SET PRINTER ON

SET PRINTER FONT "FoxPrint",10
? "This is a test"
prow_before=PROW() &&Returns 1
pcol_before=PCOL() &&Returns 14

SET PRINTER FONT "Arial",12
prow_after=PROW() &&Returns 0.714
pcol_after=PCOL() &&Returns 15.556

SET PRINTER OFF
SET PRINTER TO
The numbers I showed in the comments above are the results on my printer. The numbers you get may be different. The decimal portion of the prow() and pcol() values are dependent on the resolution (dots/inch) of your printer. For example, let's look at 10-point FoxPrint on a 300-dpi Laser Printer. This font has a 12 characters/inch pitch horizontally, which comes out to 300/12=25 dots/character, so the most horizontal precision you can achieve in column coordinates is 1/25=0.04. By the same token, a 10-point character is 10/72 inches tall (1 point=1/72 inch). So 300*10/72=42 dots/character vertically, and vertical precision is 1/42=0.0238. If we analyzed the same size character on a dot-matrix printer with 144x120 (vertical x horizontal) dots/inch resolution, you could get no more precise than 0.05 units vertically (20 dots) or 0.10 units horizontally (10 dots).
All that this precision stuff above means is that you can only place objects on the printed page with a limited amount of accuracy, and that depends on your printer. For example, if I attempt to position the 300-dpi laser print head by issuing the command @12.03, 15.03 the print head will actually be positioned at the closest dot coordinate, which is actually 12.0238, 15.04. On the 144x120 dot-matrix printer, the actual coordinates would end up being 12.05,15.00. You can verify this by looking at the values of prow() and pcol() when positioning your output via the @say command.

The ? command has an interesting property: It will always move the print head to the next integral printer row. Try the following code:


SET PRINTER ON
SET PRINTER FONT "Arial",10

? "Line 1" &&Prints in 10-point Arial
? "Line 2"
? "Line 3"
? "Line 4" FONT "Arial",11
? "Line 5" FONT "Arial",11
? "Line 6" FONT "Arial",11

SET PRINTER OFF
SET PRINTER TO
You'll notice that the first 3 lines appear normal, but lines 4 through 6 are spread apart vertically. This is because FPW is advancing the print head to the next integral 10-point Arial row (since that is the active set printer font). Since 11-point Arial is slightly taller than 10-point Arial, the ? command is forced to do a line-feed to the next available 10-point row, which ends up being 2 rows below the 11-point line.
The same thing happens if you mix fonts on the same line. FPW somehow keeps track of the tallest font and performs a line-feed far enough down for that tallest font to be visible. Output the following to your printer:


? "10" FONT "FoxPrint", 10
?? "12" FONT "FoxPrint", 12
?? "30" FONT "FoxPrint", 30
?? "20" FONT "FoxPrint", 20
? REPLICATE("X", 20) FONT "FoxPrint",10
You will notice that the line of X's on that second line prints just below the 30-point characters of the first line.
By the way, this "integral row" phenomenon with the ? command also occurs when outputting to the screen.



--------------------------------------------------------------------------------
there, CHR(13) + SPACE(there), SPACE(there-here)) FUNCTION PdObject PARAMETERS theobj, objstyle _PDPARMS[2] = .F. _PDPARMS[3] = .F. RETURN theobj

genricpd.app.
You can put this Generic pdsetup into place by executing the following two commands:


_GENPD = "GENRICPD.APP"
_PDSETUP = "Generic"
You may need to fully qualify the genricpd.app in the above _genpd line if the .app is in a different directory. You can either execute the above 2 commands from within FPW or put the following 2 lines into your config.fpw so that the Generic pdsetup is in effect every time you start FPW:

_GENPD = "GENRICPD.APP"
PDSETUP = "Generic"
By the way, it's interesting to note that only the _genpd="genricpd.app" line is required in your config.fp if you are starting FoxPro/DOS. FoxPro/DOS automatically executes the _genpd application on startup; whereas, FPW does not. That is why you must add the pdsetup="Generic" to your config.fpw.
Because of the way I've written genricpd.prg, you can put almost any string into the _pdsetup system variable and it will cause the pdsetup to be in effect (and will set the system variable _pdsetup to "Generic" anyway). The exceptions are:


_PDSETUP = "" &&Turns the pdsetup off
_PDSETUP = "?" &&Toggles the pdsetup on/off
_PDSETUP = "-" + &&Does not actually execute the genricpd.app
The reason for the "?" toggle is because of how FoxPro/DOS calls the _genpd application from its File Menu's Printer Setup Option. And, as outlined in the FoxPro Printer Driver documentation, setting _pdsetup to any string that starts with a dash ("-") will set the _pdsetup system variable to the portion of the string after the dash, but will not actually execute the _genpd application.
Once you have the Generic pdsetup active, then all printer output in FPW will be just like printing without a pdsetup in FoxPro/DOS, as long as you follow the rules I stipulated in the "Final Thoughts" section of this document.