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

[Bob Sneidar]

I've seen this happen with Copiers when scanning to file. Since the credentials 
being used are valid, a placeholder for the file is created by the system, but 
when the write of the data is attempted, it fails, either due to UAC or some 
sandboxing issue. This has the effect of leaving a 0 byte file in place with 
nothing in it.

Bob S


On Aug 1, 2016, at 09:05 , Dan Friedman 
> wrote:

The file was being created, but it was 0 bytes.

___
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

Re: 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  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

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

[Paul Dupuis]

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  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
>


___
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

MORE HELP with: open printing for pdf...

[Dan Friedman]

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  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