Blank pdf from vfp report form

[divaad]

Hello Everyone/anyone,

I am trying to convert a vfp report into a pdf so I can then email it.

I create the report and then convert it into pdf, but when I email it, the pdf is just a blank page.

I have prompted the printer to preview the report as well and this works but the pdf returns blank.

Any suggestion to what I am doing wrong? Below is my current code:

Thanks in advance for any and all advice,


REPORT FORM dbpaitlf NOCONSOLE TO PRINTER preview
********** Create pdf file for Margin Report **********
=MESSAGEBOX('Creating Margin Report pdf.', 0+64+0, "VBPA")
lcpdfname1 = "MarginReport.pdf"
lcFilename1 = lcpath+"PDFS\" + lcpdfname1
oPDF = CREATEOBJECT("wwXFRX")
oPDF.PrintReport(lcpath + "Reports\dbpaitlf" ,lcFilename1)
*******************************************************

 

[Tore Bleken]

For all my reports, also PDFs, and to email them, I use the totally free FoxyPreviewer. Don't be fooled by its name, though, it's extremely powerful.

 

[divaad]

Unfortunately my company doesn't use foxypreviewer and it is not an option at this point. I use similar code in other programs and it works fine. I do not know if there is something in this program or report that returns a blank when clearly the print preview shows otherwise.

Thanks for your help.

 

[GriffMG]

Could it be a positioning thing, put a go top just before your report is run the second time
Check the currently selected work area too - that kind of thing?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Olaf Doschke]

Could be as simple as having the report embedded in the EXE and not on HDD. So the normal VFP reporting works and sees the EXEs internal dbpaitlf.frx, but XFRX needs it external?
I'm no XFRX user, so that's not just a rethorical question.

Bye, Olaf.

 

[GriffMG]

I use XFRX a lot, running it like this

		SET PATH TO (m.WHEREAMI)  && m.WhereAmi points to where the runtime support for XFRX is
		LOSESSION=  XFRX('XFRX#INIT')
		LNRETVAL = LOSESSION.SETPARAMS("report.pdf",m.TEMPDIR,.T.,,,,"PDF") && m.TEMPDIR is a temp folder for the output
		IF LNRETVAL = 0
			LOSESSION.PROCESSREPORT("PRNCDOCS")
			LOSESSION.FINALIZE()
		ENDIF
		RELEASE LOSESSION

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[JRB-Bldr]

I create the report and then convert it into pdf,

But you say that in VFP Preview the report looks fine.

Before you send the document as an email, have you opened the PDF document locally to examine how it looks?

Also, why are you doing this as a 2-step process.

1. create the report​

2. convert the report to PDF​

Personally I most often use Bullzip (free) and create the PDF document directly from the FRX with no in-between steps - the Bullzip 'printer' is used to output the document.

I also sometimes use XFRX to do the same thing.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

>But you say that in VFP Preview the report looks fine.
That's why I think it's the visibility of the report as embedded file in the EXE

This line is making the preview
[pre]REPORT FORM dbpaitlf NOCONSOLE TO PRINTER preview[/pre]
The preview is not forwarded to XFRX though.

This is starting the report once more and with XFRX
[pre]oPDF.PrintReport(lcpath + "Reports\dbpaitlf" ,lcFilename1)[/pre]

And that's also why Griff has a good idea with

go top just before your report is run the second time

It's a good observation the report is rerun.

In foxypreviewer the PDF generation is done from the preview, in bullzip it'sdone via a virtual printer driver creating a PDF file instead of output for a printer port. Any of these alternatives run within the same report run and not separate.

As said I'm no XFRX user, but it seems to me it's doing its own parsing of the report to create any output, no matter if in the form oPDF = CREATEOBJECT("wwXFRX") and oPDF.PrintReport() or loSession = XFRX('XFRX#INIT') and LOSESSION.PROCESSREPORT(), XFRX is not running with the report engine of VFP or its output for printers, it's starting on the level of the frx and fully implementing it's own report engine. No wonder it's more expensive. It's around since before we had so many hooks into events of the VFP report engine the REPORTBEHAVIOUR 90 gives us.

It might be, that running XFRX in any of both ways can see the embedded FRX, too, then not going back to top of the previewed data can be the reason the XFRX run does not see any data to print and ends empty. It's true a record pointer is at EOF after a report run in the rpoert driving table or cursor, so you have to go back to top again, unless the report opens its driving data in its dataenvironment.

But even the filespec reports of VFP with embedded data via dataenvironment end at the end of their driving data, of course. To see put ? ALIAS(), RECNO() into the closetables method of the DE code of any of the HOME()+"TOOLS\FILESPEC\" reports. And if you restart a report at EOF and it does not reopen tables and thereby would go top in them, it ends rightaway as with an empty driving data table.

Bye, Olaf.

 

[divaad]

I have tried just running the report the first time for XFRX and it still prints a blank. I tried adding a goto top, still nothing. I am not sure how to check the data environment, correct the form for visibility, or if it is embedded in the exe or hdd. Could the following be an alternative though, if I use 'TO PRINTER PROMPT' after the report name I can then manually route it to the Adobe PDF printer and convert it to a pdf and save it to a certain location. Is there a way that I can have VFP automatically do this in the program? Choose the printer (Adobe PDF), Set the filename (MarginReport), set the location (D;\Apps\Int\PDFS\, and choose okay to process?

Thank you all for your comments,

David

 

[GriffMG]

D;\Apps\Int\PDFS
That's not going to work D:\Apps\... perhaps

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Mike Lewis]

Are you by any chance launching the report from a grid? If so, it's likely that the grid is changing the work area, and that could be the cause of the problem.

For a deeper explanation, see VFP reports not showing the same data as the preview.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[divaad]

Yeah that was a typo - I meant D:\Apps\Int\PDFS\<filename.pdf>

 

[divaad]

Sorry I am new to Foxpro. What do you mean launching from a grid? I read the link but I am not sure where to set the focus to, to be able to test your advice?

 

[Scott24x7]

divaad,
I think what Mike means is, is your mouse over the grid, and are you clicking, or right-clicking or pressing some in-grid object that causes the report to run? Or are you causing the report to run (what trigger) from some other area in the application?


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[divaad]

I am clicking a command button on the form to trigger the report.

David

 

[Mike Lewis]

Scott, you're right. That's exactly what I meant. But it seems to have been a red herring.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Scott24x7]

I David,
I didn't see anyone else ask this either, is there more than one PDF "creator" on that machine? (And have you gotten other PDF creations to work from this machine?)
Look for culprits like Cute PDF or other PDF "makers" (even some versions of Acrobat). There may be a conflict. You may have checked all that already, but I like to see if we've established the "cleanliness" of the environment as well...

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[JackTheC]

For some reason I had always problems with reports. Maybe because printer info of the (default) printer the report was created on is stored in the FRX/FRT.
That's why I always cleanup the report file. 15 years back I wrote something like this:
Sorry for the crazy split. It's this site...

private ab,bst,tt,rp,map
close all

map=getdir()
if empty(map)
	return
endif

ab=adir(bst,map+'*.frx')
for tt=1 to ab
	rp=map+bst(tt,1)
	use (rp) excl
	locate for objtype=1 and objcode=53
	if found()
		repl tag with ""
		repl tag2 with ""
		if 'ORIENTATION=1' $ upper(expr)
			repl expr with 'ORIENTATION=1'
		else
			repl expr with 'ORIENTATION=0'
		endif

		repl expr with expr+chr(13)+chr(10)+'PAPERSIZE=9'
		repl expr with expr+chr(13)+chr(10)+'COPIES=1'
		repl expr with expr+chr(13)+chr(10)+'DUPLEX=1'+chr(13)+chr(10)
	else
		=messagebox(rp+' has no expr/tag/tag entry???')
	endif
	use
	use (rp) excl
	pack
	use
endfor

=messagebox('Ready')
close all

 

[GriffMG]

I do the exact same thing!
But I am a luddite

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Scott24x7]

Ah, yes, that brings back memories as well!
Particularly when you're in a user environment that has a vastly different set of printers, particularly to the one the report was developed with. Had completely forgotten about that...

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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