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 <p...@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!
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
