Program flow seems lost after calling print2pdf

[Forgetabull]

Hi everyone,

I'm quite new to foxpro development. I'm working in MS Foxpro 9. Here's my code snippet:

IF FILE(lcpdf)

SET PROCEDURE TO print2pdf.prg ADDITIVE

lodist = CREATEOBJECT("Print2PDF")
lodist.ReadIni()
lodist.cPSFile = lcpdf
lodist.cOutputFile = FULLPATH(THIS.output_file)
lnresult = lodist.MakePDF()
lodist = NULL

SET PROCEDURE TO

DELETE FILE (lcpdf)
ENDIF

After returning to the main thread (main.prg) it seems to get lost in the program flow and can't find any of the class definitions or other foxpro files from the main program and subsequently crashes. Any idea ?

cheers,

Alan

 

[Scott24x7]

The problem is yoy issue:

SET PROCEDURE TO print2pdf.prg ADDITIVE
Then you:

SET PROCEDURE TO

If MAIN.PRG was your PROCEDURE file, adding the "ADDITIVE" to print2pdf.prg tells VFP to add it's contents into the list of things that you would have from MAIN + print2pdf.

When you "release" the applications PROCEDURE FILE (Issuing SET PROCEDURE TO basically says "set it to nothing"), you lose all of it.

I don't know what you have in your print2pdf.prg file (the only call I see in your code that follows is "MakePDF()", which isn't a VFP function. Not sure what that acutally does but you could say:

lnResult = DO MAKEPDF in print2pdf.prg

that will probably give you the same result without issuing the "SET PROCEDURE TO print2pdf.prg ADDITIVE, making it then unnecessary to "release" it.

Or others may disagree with this, you could leave the ADDITIVE and take out the SET PROCEDUDR TO line. That will just leave the functions available in the ADDITIVE code available to other parts of your application. But, if your objective is the need to "make it work, figure out the why later" that may be your fastest route.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

SET PROCEDURE TO without any file name specified kills all your previously set procedure files to find procedure, functions and class definitions etc. It doesn't just remove the last added reference. So simply don't do that. What's correct is using the ADDITIVE clause in the setting of the print2pdf.prg. Always using ADDITIVE you never let VFP forget or close any other references and it automatically removes doubles. If you want to remove the print2pdf.prg you can use RELEASE PROCEDURE print2pdf.prg.

Bye, Olaf.

 

[Mike Lewis]

There is another possible cause for this problem.

I don't know exactly what PRINT2PDF.PRG does, but in general, when you print to PDF, the printer driver is liable to change the default directory (as seen by VFP) to the one containing the destination PDF file. This isn't a bug in any particular PDF driver; it occurs with several different drivers.

The usual solution is to save the current default directory to a variable before you create a PDF, and restore it afterwards. To be sure, you really need to do this before you print anything from VFP, because you can never know if the user is going to select a PDF driver as the destination printer.

Source: Trouble-shooting a Visual FoxPro application, under Problem #4.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Forgetabull]

Hi guys,

Thanks for all your help, I've implemented the changes suggested by Scott. Interestingly enough, printtopdf was a third party component I was using as a wrapper on ghostscript. It appears as though it had a bug in it as the Path set upon exiting the routine was set to 'LCPATH', so MikeLewis, you were spot on the money too !

 

[Mike Lewis]

Glad to have been of help, Alan. Be sure to come back if you have any further problems.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

The current path doesn't influence the SET PROCEDURE, so even if the class would influence the current directory it doesn't explain VFP not finding any PRGs you made known via SET PROCEDURE beforehand, it's only your SET PROCEDURE TO line that cleared this memory.

Test this, if you want to test my thesis: MESSAGEBOX(SET("PROCEDURE") after SET PROCEDURE TO print2pdf.prg, then again MESSAGEBOX(SET("PROCEDURE") after SET PROCEDURE TO, the first messagebox will at minimum show print2pdf.prg, the second messagebox will show none, as you cleared that memory of VFP. You may also put the messagebox right after using MakePDF() to reveal how the PrintPDF class acts on the PROCEDURE setting, but it's very likely it doesn't and it's impossible any external component like Ghostscript influences the PROCEDURE setting. That is a Foxpro internal setting and not a system environment variable anything outside VFP has access to, the same goes to SET DEFAULT. The PROCEDURE and DEFAULT setting can only be influenced by VFP code, so a portion of the print2pdf code would need to be VFP code and could cause anything, but mainly your SET PROCEDURE TO is wiping all memory of PRGs.

Another independant test to see the behaviour of it:

*There are 4 well known prgs in HOME(): genhtml, genmenu, scctext and vfpxtab
CD HOME()
SET PROCEDURE TO genhtml.prg, genmenu.prg, scctext.prg, vfpxtab.prg ADDITVE
Messagebox(SET("PROCEDURE"))
SET PROCEDURE TO
Messagebox(SET("PROCEDURE"))
SET PROCEDURE TO genhtml.prg, genmenu.prg ADDITVE
Messagebox(SET("PROCEDURE"))
SET PROCEDURE TO scctext.prg, vfpxtab.prg ADDITVE
Messagebox(SET("PROCEDURE"))
* To remove only a single prg:
RELEASE PROCEDURE genhtml.prg
Messagebox(SET("PROCEDURE"))

Do you see the "mechanics" of the commands now?

If you only want to clear print2pdf.prg you added via SET PROCEDURE TO print2pdf.prg ADDITIVE, then you should RELEASE PROCEDURE print2pdf.prg and not SET PROCEDURE TO.

Another thing you can do is to STORE SET("PROCEDURE") TO aVariable and at the end SET PROCEDURE TO &aVariable.

Bye, Olaf.