Was Working...Printing from Fox 2.6 to Adobe PDF printer. 2

[jlg13]

Hi Experts!

My goal is to convert a batch of TXT files (that were created by a Fox program)to PDF using the Fox application.

I already have a program that takes each TXT file, sends to the Printer, converts to PDF. In fact, it has been working successfully for years, until a server crash and we lost some setting attributes. I manages to solve the problem outside of Fox which requires several manual steps whereas the Fox program processes all in a fraction of the time.

Some Background: The TXT files are created with a specific number of characters for width and a specific number of lines per page. This along with using Lucida Sans Handwriting font (which uses the same spacing for each character) the PDF is perfectly formatted. I am attaching TXT/PDF samples of before crash and after crash for visuals when using Fox program.

Please note that I can create the before server crash result outside of Fox by Open Windows Explorer, highlight up to 15 of the TXT files, then EITHER (drag/drop them on the adobe PDF printer on my desktop. Windows asks if I want to process multiple files, I reply YES and away it goes and desired result achieved.) OR (RIGHT CLICK the highlighted files, then choose Print, and it immediately processes the TXT into PDFs) Everything is PERFECT. I do want to note that IF I highlight more than 15 files, the RIGHT CLICK ->PRINT option is NOT available to me and I am left with the option to "Convert to Adobe PDF" which DOES NOT work. formatting is all messed up. Both of the successful processes require some important preliminary set up steps:

1. I must first establish some settings in NOTEPAD, which as you may know, once set, all notepad files open with your last adjusted settings.
2. Then... FORMAT -> FONT, I set the font to Lucida Console, Point size 7 under format.
3. Then... File -> Page Setup, I set paper size to A4 and all margins to ZERO except BOTTON which I set to 65
(Note if any of the above are off... Pont size 8 or margin 64, it throws everything off)

4. Then... I adjust the Adobe Pdf Printer Properties. I highlighted in yellow a few settings I had in our tech notes

Doing 15 at a time is tedious and time consuming... and every once in a while it encounters a problem if it processes too fast. This is why we have a 1 second wait coded in between sends which slows the processing down when executed in Fox...

Here's a PDF using the manual system which is identical to the how it worked from Fox before the crash.

https://files.engineering.com/getfi...abe4-4046-b44c-e353dff4eb4b&file=b4_crash.pdf

Ok, so the PRG that send ALL of the TXT files to the Printer Prompt. The printer dialog box opens once in case I need to reset Adobe as the default printer. I click "OK" and away it goes converting one TXT file at a time to PDF until all the files are complete.

Here's what I am getting now

https://files.engineering.com/getfi...7ddc-4d17-a7b2-8710dfe8afd2&file=FoxAfter.PDF

The following is a procedure the executes the printing. You will see THREE "SET PRINTER FONT" lines. The 2nd is the one that had been working for YEARS. I commented it out to try a 3rd based on some of the images I provided.

In my mind, if it prints fine from NOTEPAD, it should print fine from FOX. Hoping someone has an idea. <fingers crossed emoji>

I hope I provided enough info.... Thank you!

PROCEDURE Print_it
*  Print reports
*!
*!      Called by: RptByDates         (procedure in MA_PRINT.PRG)
*!               : SkolsByRng         (procedure in MA_PRINT.PRG)
*!               : AllSkols           (procedure in MA_PRINT.PRG)
*!*****************************************************************************
ACTIVATE WINDOW wtest NOSHOW
IF lcOption = "EOM"  && Collection 03/07/10
*  SET PRINTER FONT "LUCIDA SANS CONSOLE REGULAR",7
*  SET PRINTER FONT "LUCIDA SANS TYPEWRITER REGULAR",7
  SET PRINTER FONT "LUCIDACONSOLE REGULAR",7
ENDIF
IF (llAllSkols OR llRange OR llDateRng) AND ll1stTime  && 01/19/2003
  TYPE (lcPrtFile) TO PRINTER PROMPT
  ll1stTime = .F.
ELSE
  IF llAllSkols OR llRange OR llDateRng  && 01/19/2003
    TYPE (lcPrtFile) TO PRINTER
  ELSE
    TYPE (lcPrtFile) TO PRINTER PROMPT
  ENDIF
ENDIF
DEACTIVATE WINDOW wtest
IF llAllSkols OR llRange OR llDateRng  && 01/19/2003
  RETURN
ENDIF
lcMsg = "FILE:"+gcSkip2+lcPrtFile+gcSkip2+"Sent To Printer"
=MSGBOX(lcMsg,"",gbOK+giInfo)
RETURN

 

[Chris Miller]

Well, legacy type printing is difficult on Windows. But, if printing from a file works from Windows Explorer, then I'd replace that code with ShellExecute using the "print" action instead of the usually used "open" action:

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

ShellExecute(0,[highlight #FCE94F]"print"[/highlight],"c:\some\of\our\textfiles.txt","","",1)

To first ensure the Acrobat printer is used, well, you could again use the Windows API to set the default printer. That's explained nicely by Sergey Berezniker here:

https://www.berezniker.com/content/pages/visual-foxpro/changing-windows-default-printer

Ideally, you set the default printer back to what it was, especially if it wasn't the Adobe PDF printer, as you'd not want to mess with the user's default choice.

I'm pretty sure that works as you say what also works is:

RIGHT CLICK the highlighted files, then choose Print

Normally VFP printing goes through the usual Windows printing drivers and also works with PDF printers, but with an FRX as a basis, not just any text files. It seems to me your text files are specially formatted and may even contain specific control codes for this Adobe printer driver, well, such things don't go over usual printing and not via outputting a file via some printer port in Windows, that's DOS style printing. You could perhaps also run an actual DOS or a DOS clone to get this working, but I think it's simpler to modernize this with ShellExxecute().

The only task remaining to do with VFP is to let users pick files or select them by date ranges ADIR() could help you also figure out which files are within a date range as file dates are part of the result array of ADIR(). Obviously, you may also move printed files into a folder for processed texts, whatever, but the main ingredient will be to use the "print" action of Shellexecute and this will work the same way as manually choosing "print" from the context menu of a file.

Chriss

 

[Mike Lewis]

I would suggest a completely different approach - and a simpler one.

1. Create a report (using the VFP report designer). Keep the headers and footers empty; no grouping; in the Detail band, insert a single field; make the field nearly as wide as the page; set its expression to (say) csrText.Field1; set its font to anything you like (does not have to mono-spaced); In its Properties, specify "Fix relative to top of band" and "Stretch with overflow". Name the report (say) TextReport.

2. Write a program along the following lines:

CREATE CURSOR csrText (FIELD1 m)
APPEND BLANK
APPEND MEMO FIELD1 FROM <name of your first text file> OVERWRITE
REPORT FORM TextReport TO PRINTER <name of your PDF printer driver>

3. That should be enough to print the first text file. So, next, modify the program to loop through all the text files, performing the APPEND MEMO and the REPORT FORM each time round the loop. (Use ADIR() to get the names of the text files.)

This is not meant to be a complete working solution. It's just to give you an idea of how you might go about it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

I agree this would also work. It's not the best way to upgrade your reporting to use FRXes, but Mike's proposed solution would unbind you from Notepad settings to get the same result. I think, if you print files with TXT extension they are printed through Notepad anyway, also with ShellExecute, that's why its font settings become the print layout. Whereas in an FRX this is part of the FRX itself.

You have many more options within an FRX, though. The entry point of an FRX should actually be the code you have to generate the text files because the report designer offers much more than the choice of page size, fonts, and their size, you can group data, have report variables that can sum, count, average, and do some more operations during the reporting, can number pages, have captions in bold, include images, and many more things you can't have in text files.

I'd first just use a solution that's known to work, when changing to FRX the first step to change would be the code generating the text files you print, because the whole idea of FRX reports is to layout the design and have standard captions, page headers and footers, summaries, groups and more, and feed in the raw data into that, like sales positions of an order, there's no intermediate step to create files to feed into a printer, the report itself is that step and turns the raw data into a pretty formatted output. And that enables things like positioning report elements and using proportional fonts and many more things. It could really also cut down the code you now need to format the text, position items, or whatever you do in the text file generation preparation step of your reporting, because that all goes into the visual design of a report.

I bet you have a lot more things to adapt to work in the VFP9 migration of your code before stepping into the new features of FRXes, though. It's your choice, of course. Mike's solution still also has your text files as its basis, it removes some dependencies on notepad settings, which is an advance, but to me, the logical step is to use ShellExecute first and when going for FRXes go in with redesign in mind, using FRX features to have a real benefit from that change.

If you go for Mike's solution, I would add one step to it to ensure you don't fall into a trap: Uncheck "Save printer environment" in report properties. Or use that feature and pick the Adobe PDF printer driver to bind printing that report to that printer driver, that's perhaps also logical in your case. The reason to usually not embed printer info is that it means binding a report to a specific printer driver and if that's not available for a user that would mean errors, in the best case falling back to some other (default) driver and getting weird results. Not embedding printer info then also enables to use the FRX for any printer, too. So that's also a step into the freedom of choice of other printers, including other PDF printers. Besides you get a preview step, if you want to offer it.

Chriss.

 

[Mike Lewis]

Just to add a small point ....

You wrote that you are using "Lucida Sans Handwriting font (which uses the same spacing for each character)". I think you meant Lucida Console.

Lucida Console is a mono-spaced font. I can see why you want that, give that you are using the TYPE command to output the text, and that command requires text to be mono-spaced in order to correctly line up the columns. However, if you decide to adopt my solution, you would be able to use any font you like, as the report writer would take care of the character spacing.

Another advantage would be that you would get the correct pagination. You could also get page headings, page numbers, etc. if that is what you want.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[jlg13]

Thank you gentlemen.

I know I provided a lot of information and it may have been missed from the title that I am using Foxprow 2.6, not VFP.

The reports are also not being created using the forms tool. The program literally establishes a TXT file and starts outputting data to the file (It actually creates 8 different text files and are merged into 1 at the end). Not sure I explained that well enough.

Based on the above, I wonder which of the responses would still be applicable?

Thanks much for taking time to review all and replying. I feel a solution is lurking despite 2.6a

Joe

P.S. if there is anything else I can provide, let me know. My dad (since passed 2018) was the original programmer. I have maintained best I can, largely due to this forum. I also have someone with a lot more knowledge than me helping last 2 years and thought I would start here and give him some ideas. THANK AGAIN!


@Mike YES ON FONT: LUCIDA CONSOLE!!

 

[Chris Miller]

the report writer would take care of the character spacing.

Well, I disagree with that aspect when you just use a single report field to print a memo, using a proportional font then ruins a column layout you could do with same count of characters. That's exactly what a proportional font destroys.

To get well-spaced output in an FRX you need to have single-field data and single-field report controls positioned the way you want them at the design stage. That way they can align into columns as you like, but that requires a more detailed report layout with - simply said - one report control per column of a list. And that is adding a lot to the overall task. That's why I suggest postponing an FRX layout to a later stage, but then doing it with that in mind.

We have no overview, about how many different report types are done this way now in that software, all using monospace characters to align text into columns, for example. That's not covered by a single FRX. Like I already explained, you'd replace your text file generation with reports and as much different code you have for the different text types you generate currently, as many different reports you'd have instead that allow you to do layout visually, not by code. And reduce code by visual design.

Chriss

 

[Chris Miller]

I am using Foxprow 2.6, not VFP.

Pretty sure FRXes already existed in FPW2.6, as there also are some FRXes in the VFP(9) installation that describe FRX files also in 2.6 format.
Also here's a little info about converting 2.6 reports that show the old designer, you should find it in your Foxpro installation:

https://www.alvechurchdata.co.uk/foxconvert4.htm

And surely you also have the DECLARE command to make use of ShellExecute. So both options are still on the table. You'll not have the report property of embedding or not embedding printer info I talked about, but there is an older approach for that, too.

You might give both solutions a try. I think a simple test of ShellExecute is easier to do and if that already fails you could go for FRX report design.

Chriss

 

[Mike Lewis]

Chris, I take your point about using a proportional font. I must have been thinking of a case where each column is a separate field.

Joe, you're right. I missed the 2.6 in the title. In general, I think my solution would still work, but would need some adjustment. In particular, did we have CREATE CURSOR in 2.6? I don't remember. (I so wish I handn't thrown out all my old manuals the last time I moved house.) If not, you could always use a permanent table, and zap it after each run. The point is that the general approach might still work even if the actual syntax doesn't.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

did we have CREATE CURSOR in 2.6? I don't remember.

Well, it's not the core part to have a cursor, you could also create a DBF table and append files into a memo field. That's all there.

But I realize I think DECLARE DLL was introduced in Foxpro 3, so that's not available, you had to use Foxtools.fll to declare functions of the Windows API in 2.6, that's done this way:

Set Library to foxtools.fll
nShellExecuteHandle = RegFn32("ShellExecute","ICCCCI","I","shell32.dll")
And then call it by 
CallFn(nShellExecuteHandle,0,"print","c:\some\of\our\textfiles.txt","","",1)

Chriss

 

[jlg13]

ok, thank you guys. I'll dig into this over the weekend and see if I can resolve.