Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
PDF Form Viewing, Field Editing and Printing
Message
General information
Forum:
Visual FoxPro
Category:
Third party products
Environment versions
Visual FoxPro:
VFP 8 SP1
OS:
Windows XP SP2
Network:
Windows XP
Database:
Visual FoxPro
Miscellaneous
Thread ID:
00953565
Message ID:
00954520
Views:
30
Yes, I tested this yesterday and well into the night lastnight and determined the same. It looks like I will have to take a different route. We have two methods that work right now, but neither is completely ideal. However, I will continue researching this until I come up with the ideal solution (ha ha) for our requirements. It looks like we may have to settle with one of our two solutions for now until I have the time to research the latest Adobe Designer file structure (xdp) and program the activex myself in Delphi.

So far we:

Option 1:
1. Store the pdf form in a memo field.
2. Use a VFP form to enter/modify data for each pdf formfield and store the values in our app's tables.
3. Programmatically create the pdf form's associated .xfdf xml file on the fly that contains the data for each pdf form field.
4. Create the pdf form on the fly from the form stored in the memo field.
5. Launch Adobe Reader to view the pdf form with the data from the .xfdf xml file.
6. When Adobe Reader is closed, delete the .xfdf and .pdf files.

Option 2:
1. Store the pdf form in a memo field.
2. Use a VFP form to enter/modify data for each pdf formfield and store the values in our app's tables. Each data entry control on the VFP form has the corresponding pdf form's formfield's fieldname in its tag property.
3. Create the pdf form on the fly from the form stored in the memo field.
4. Launch a vfp form that has the pdf.ocx control on it to view the pdf form with the form fields filled out in the form, and the Gnostice pdftoolkit activex component on it that allows us to step through all form fields on the pdf form before it is launched in the pdf.ocx and populate the formfield values with the corresponding values in our tables.
5. Delete the temporary pdf file created.

So far, option 2 is the best because it uses generic functions that work for all forms whereas option1 requires us to setup the layout for the xml file for every form. We are going with option2 unless we find a better solution...

>>The problem we are encountering is that the Adobe activex ocx will only save the changes to disk if the workstation has the full version of Adobe Acrobat installed. If only Adobe Reader is installed then the pdf form is saved without
>
>I'm not sure this will be of much help, but I've been down this road as well and didn't find any particularly great solutions. From what I saw, the Javascript that you can embed in the document has a bunch of security issues (and missing objects) that pretty much keep you from being able to write anything to disk (or anywhere else that might be useful).
>
>I did eventually find some info. about a way of pushing form variables into some configuration file that Acrobat has. The major downside to this was the limited amount of space available for this (less than 1k, if I remember). I'm sorry, but I don't have the link. I found for most forms that this wasn't nearly enough.
.·*´¨)
.·`TCH
(..·*

010000110101001101101000011000010111001001110000010011110111001001000010011101010111001101110100
"When the debate is lost, slander becomes the tool of the loser." - Socrates
Vita contingit, Vive cum eo. (Life Happens, Live With it.)
"Life is not measured by the number of breaths we take, but by the moments that take our breath away." -- author unknown
"De omnibus dubitandum"
Previous
Reply
Map
View

Click here to load this message in the networking platform