MORE HELP with: open printing for pdf... SOLVED

[Dan Friedman]

Hello again!

In case you were following along, I finally figured this out...  In an attempt to deliver my application as easily as possible, I have my customers download only the exe from my site -- just this one file.  All extra files (extra stacks, images, dlls, etc.) are the downloaded by the exe at runtime.  Works perfectly!   In this case however, there was a problem downloading the "revpdfprinter.dll" file.  The file was being created, but it was 0 bytes.  So, when the app checked to see if the file was there, it was -- but it was invalid.  So, I put in an extra check to verify that the size of the dll is exactly 753664 bytes.  If it's not we download it again.  If it fails again, then I point them to a web page that has the file and instructions.  Problem solved.

Time for a fresh cup of coffee.

-Dan



> Hi Dan,
> 
> i am using revPrintText in my printing to PDF. i.e.
> 
> open printing to pdf tFile
> revPrintText theHTMLText
> close printing
> 
> where theHTMLText is basically 'the htmlText" or a target field. This is
> working for me in *most* cases. Our field content that gets converted to
> a PDF ranges from plain text to very rich content, including embedded
> images in the field (via the imageSource of char x). This produces a
> single, properly paged, PDF. However with some content - we have yet to
> figure out what field content triggers it - we get a script execution
> error in revPrintText
> 
> Object: property is not an integer: 4294907844 (Line 0, column 0)
> Chunk: can't set property:  (Line 162, column 22)
> Object: can't set object property: 4294907844 (Line 162, column 7)
> set: can't set property: 4294907844 (Line 162, column 1)
> repeat: error in statement:  (Line 141, column 1)
> Handler: error in statement: revPrintText (Line 141, column 1)
> Object ID: stack "revprintlibrary
> 
> 
> So, we may have to change to using print card or something else. I have
> no experience at using open printing for PDF with anything other than
> revPrintText, so I am sorry, but I don't know what may be the cause of
> the problem you've run into.
> 
> -- Paul
> 
> On 7/28/2016 2:11 PM, Dan Friedman wrote:
>> Monte (and Paul),
>> 
>> Thanks for reporting your findings.  I have been struggling with this issue for some time (with LC 7.0.1).  Adding the default folder to the path to the DLL fixed the problem.
>> 
>> However, now that it's PDFing, a new problem exists.  If I "open printing to pdf" and then run multiple "print card" commands, each print comes out as a separate document and I am asked to select a location to save the output for each page.   I haven't issues a "close printing" command yet, but it's still outputting separate PDFs.  It works fine in the IDE, it works fine in the Mac Standalone, but I get this odd behavior on with the Windows standalone.
>> 
>> One note...   I "open printing to pdf" in stack A.  Then, I open stack B and do the "print card" commands.  Then, I close stack B and stack A issues the "close printing" command.  I then repeat as needed.   I don't think this matters as it works in the IDE and on the Mac.
>> 
>> 
>> Any thoughts?
>> 
>> Thank you in advance!
>> -Dan
>> 
>> 
>>> On 27 Jul 2016, at 4:43 PM, Paul Dupuis <paul at researchware.com> wrote:
>>> 
>>> Monte,
>>> 
>>> Thank you so much - exactly that - so for LC6.x I added the follow which
>>> address the problem whether in the IDE or standalone
>>> 
>>> put the defaultFolder into tSaveDefaultFolder
>>> if (the environment is "development") then -- IDE
>>> set the defaultFolder to specialFolderPath("engine")
>>> else -- standalone
>>> set the defaultFolder to appPath()
>>> end if
>>> 
>>> -- do my PDF printing
>>> 
>>> set the defaultFolder to tSaveDefaultFolder
>>> 
>>> If I every see you at a LiveCode Conference (I have to attend Edinburgh
>>> via webcast this year), I owe you drinks or a meal or both!