>>I have an application written in VFP 6.0, SP3, running on Windows NT.
>>Our application allows the user to output ther report in .PDF files, and also to e-mail these reports. We've been using Adobe Acrobat 3.02, and it's worked fine. However, some of our customers (as well as our internal users) are installing Acrobat 4. Now the code no longer works properly. Here is the "meat and potatoes" of the code, before any code changes. For clarity:
>>tcPrinter is the printer destination. In this case is is "Acrobat PDFWriter"
>>tcOutputDestination is the filename we are using to store the output (typical contents would be "FILE: c:\temp\12345678.pdf"). This file is then sent as an attachment to an e-mail message.
>>
>>
>>IF .NOT. EMPTY(tcPrinter) .AND. .NOT. 'DEFAULT' $ tcPrinter
>> SET PRINTER TO NAME (tcPrinter)
>>ELSE
>> SET PRINTER TO DEFAULT
>>ENDIF
>>
>>** For some reason, when we are using Acrobat on Windows NT, we need to set the print output to the printer rather than to a file.
>>** this problem does not occur on Win95 or Win98.
>>IF 'WINDOWS NT' $ UPPER(OS()) AND "ACROBAT PDFWRITER" $ UPPER(tcPrinter)
>> lcOutputFile = "PRINTER"
>>ELSE
>> lcOutputfile = SUBSTRC(tcOutputDestination, AT_C(':',tcoutputdestination)+1)
>>ENDIF
>>
>>REPORT FORM (tcLayoutName) NOCONSOLE TO (lcOutputFile)
>>
>>As I said, under Acrobat 3, this works fine. The output is going to the printer, which is the Acrobat PDFWriter, and the report appears in the file "c:\temp\12345678.pdf". However, under Acrobat 4, this code sends the report output to "PRINTER.TXT.PDF", as well as creating a zero-byte file named "PRINTER.TXT". As I stated in the comments, the code works fine with Acrobat 4 on Win95/98.
>>
>>Thinking that the fix we did for NT was the problem, I commented out the line that sets lcOutputFile to "PRINTER". That met with success, in a way. The output now went to "c:\temp\12345678.pdf.pdf", and created a zero-byte "12345678.pdf".
>>
>>Worse, when I tested this code on a machine with Acrobat 3, I received an error saying the program could not create the output file...then it went ahead and created the file anyway, with the name "c:\temp\12345678.pdf.pdf" and a zero-byte "12345678.pdf"
>>
>>My questions are:
>> -- How can I strip off the .pdf extension that Acrobat 4 insists on putting on my report output? Did something in SP3 change so the program can detect the type of file we are directing out output to, and automatically put the correct file extension?
>> -- Does anyone know why sending the output to the printer (Acrobat PDFWriter) works fine when using Acrobat 3.02, but not when using Acrobat 4? The Adobe people are less-than-knowledgabe about FoxPro (learned from earlier conversations), so I don't know how much help they would be in fixing what is probably a FoxPro problem.
>> -- If all else fails, does anyone have any suggestions as to how I can retrieve the version number of Adobe from within FoxPro? If there really is some fundamental and irreconcilable difference between Acrobat 3.02 and Acrobat 4, I may have to write code to handle each version differently.
>>
>>
>>TIA,
>>
>>Bill
>
>Bill,
>
>I think you're the first to post issues related to Acrobat 4, so you're breaking new ground somewhere. What I would do as a temporary solution, is remark the code and let the user select the printer themselves. If they select the PDF writer it will print a PDF with the name they want. Might seem rough compared to what you offered, but it works.
>
>José


After several hours of trial and error, and more than a few blind alleys, I discovered the problem. The reason for my report snafu was.....I was using the wrong kind of macro substitution.

If you look at the code I posted, the report was actually being called with the line:
REPORT FORM (tcLayoutName) NOCONSOLE TO (lcOutputFile)

After all else failed, I took a look at this line and wondered "What if I used the ampersand substitution instead?" I went ahead and changed the line to:
REPORT FORM (tcLayoutName) NOCONSOLE TO &lcOutputFile.

PERFECT! It worked right the first time out, with no additional monkeying around with stripping off the .PDF or trying to detect which version of Acrobat I was using. I did some regression testing, and it works perfectly with Acrobat 3.01 and 3.02 as well.

After spending over 12 hours futzing around with the output file string, trying to write code to handle each version of Acrobat, and tearing my hair out with frustration, this fix that took 5 minutes to code and test turned out to be the solution. Let this be a lesson: when all else fails, go back to basics.

Bill