Report form to file then print

[Foxtrotter]

I have been tasked with splitting up a process that currently prints a report to a printer in a polling type fashion where the app continuously looks for these jobs to print. What they would like to happen is for the app to continuously print these reports to named files, then at some point later, in a different process that selects which of these files to print, it would just print that file which is already formatted for the printer which should be very fast. Currently, it is a fairly complicated report and takes several seconds to print which in the environment they are in is too long. These can be processed at night so that during the day, they can be printed in the second process.

I can successfully print to a file using report form to file. The file has all the printer codes etc that it needs. My problem is printing this file back out because I can't use a normal app eg notepad to pull it up and print it because it causes it to print gibberish and instead of 1 page I get about 50. One solution that almost works is that I can print this file using the DOS print command but it is cutting off the bottom of the A4 page and I can't figure out how to control that plus I don't really like the idea of shelling out to a DOS prompt to print the file.

I know the great minds on this forum will have any number of great ideas on how to best do this.

 

[Mike Lewis]

How exactly are you outputting the report to the file? Are you using:

[tt]REPORT FORM .... TO FILE ....[/tt] ?

And, if so, are you also using the [tt]ASCII[/tt] clause?

And what DOS command are you using to print the file to paper?

And what printer driver is intalled on the computer that does the printing? And is that same driver also installed on the machine the outputs the file?

If you can answer these question, I'm sure we can help you.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Foxtrotter]

Hi Mike,

Yes I am using the report form ... to file but without the ASCII clause

DOS command is: print /d:\\lpappserv\it_lexmark myfile.txt

The printer driver is the same on both computers and is a Lexmark T650. It is a given that they will have to use the same driver to create the output file as they do to print it. They have approximately 5 or more of the same printer dedicated for this purpose which are on contract so I believe that will not be a problem as they would all change at the same time.

This file is an invoice that contains text, a logo, and other graphics so I didn't think ASCII would work but I haven't actually tried it. It also appears that the DOS command is working OK and not cutting off the bottom of the form as I initially reported. I would like to have a better method of printing these files directly though. I tried the Foxpro TYPE command but it created gibberish.

Thanks for any help.

 

[Mike Lewis]

Given that the report contains a graphic (the logo), you are right that you can't use the ASCII option. Also, you are right that you can't use the FoxPro TYPE command: that only works with plain text files, not report files.

On that basis, I would say the way you are doing it (with the DOS PRINT command) is perfectly correct, and probably the normal way to handle this situation. Unless you have a special reason for wanting to avoid using DOS, I would stay with it. (Actually, my first thought was to use the DOS COPY command, but PRINT is better as it lets you specify the printer driver.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Foxtrotter]

Ok, Thanks. I'll proceed with that and see how this turns out speed wise.

 

[Mike Lewis]

Good. Let us know how it works out.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[TamarGranor]

I think I'd "print" to PDF and then just use ShellExecute or something to print the PDFs.

Tamar

 

[Foxtrotter]

Tamar,

I am considering that because I am creating a PDF along with the report but I'm afraid that the shellexecute some app that can print the PDF will be too slow for them. The timing of these print jobs is critical for not slowing down processing. I will try this method to see how it works. Does anyone have a suggestion of a fast app for opening a PDF, printing it, or even doing a print in a batch type operation where I could print a certain list of files. I can't create a PDF with multiple pages because I don't know what order they will want to print the files during processing but I will be able to pull a list of file names as a batch.

 

[NasibKalsi]

but it is cutting off the bottom of the A4 page and I can't figure out how to control that plus ...

Assuming, you have a Header, Details Line and Footer.

if the Details line is always 1 line ie description does not flow to the second line, it may be easy to control the page length and if it goes over certain number of details lines then issue Eject Page or Chr(12).

To print the created reports: Create another small program where you can pickup all the created reports put then in the grid on first use and continue adding as they are created. Have 2 'Check Button' s, first ToPrint and second Printed. Sort them such that printed reports appear on the bottom. Then loop through and all the files that user have checked ToPrint and print via ShellExecute. Set/Reset the both 'Check Button' according to the print status. Later on delete the printed files (after 1 day or 1 hour, etc.)

If there is a choice, go with Tamar's suggestion.

 

[Mike Lewis]

I think I'd "print" to PDF and then just use ShellExecute or something to print the PDFs.

That was my initial thought as well, but Foxtrotter said that speed was critical, and I suspect that printing a PDF will always be slower that a straight dump to the printer via the DOS command.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Foxtrotter]

Yes, speed is critical in this situation although I think I will test that out but I'm betting Acrobat Reader is not going to be all that fast to open/print/close. Maybe I can find another reader that could stay running. I'm just not sure I can control those apps. Has anyone worked with any of these apps to automate them from Fox?

 

[Foxtrotter]

NasibKalsi,

I figured out my problem with the page being cut off. Even though I had the paper size set in the report form, I didn't have the paper tray set to A4 on the printer. Once I changed that, my DOS print command is working as well as printing the report form directly.

Thanks.

 

[Mike Lewis]

There are certainly other PDF utilities that can print a file from the command line (that is, via SHELLEXECUTE()). But they all have their pros and cons. One recurring problem that I have faced is that, after the print finishes, the PDF program remains open - there's no automatic way of closing it. That's not a show-stopper, but it is a nuisance.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Foxtrotter]

Mike,

Do you remember any of those PDF utilities that you have successfully used? The PDF program remaining open may not be a bad thing unless it is creating a new instance when it opens the next PDF. This app would probably be printing around 3-5,000 PDFs per day on demand.

 

[Mike Lewis]

Do you remember any of those PDF utilities that you have successfully used?

Give me a few minutes and I'll dig out my old notes.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

OK. got it.

The utility I used was SumatraPDF. This seems to one of the fastest of the PDF viewers, and it's free.

Here's how I printed a document:

DECLARE INTEGER ShellExecute IN shell32.dll ; 
  INTEGER hndWin, ; 
  STRING cAction, ; 
  STRING cFileName, ; 
  STRING cParams, ;  
  STRING cDir, ; 
  INTEGER nShowWin

ShellExecute(0, "open", "C:\Program Files\SumatraPDF\SumatraPDF.exe",;
   "-print-to-default c:\pdf\junk.pdf -exit-on-print",  "", 1)

As you no doubt know, you only need to execute the DECLARE command once, not every time you use it.

Given that you will be printing many files at a time, you can probably omit the [tt]-exit-on-print[/tt] parameter. In fact, it might be faster to do so. But you can test that for yourself. There's also a way of directing the output to a different printer driver.

Don't forget that you will also need to install a PDF driver to generate the PDF in the first place. But at least the performance of that driver won't be critical.

I'm not convinced that printing PDFs will be a better solution than using the DOS command. But at least you now have something to play with.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Foxtrotter]

Wow, thanks Mike. I'm already creating PDFs as part of the printing process right now so that's covered. I'm with you on the thought that DOS will be faster but if the PDF's can be printed fast enough I wouldn't have to worry about creating an output file and printing that as we already store the PDFs.