View PDF in VFP Form, Edit Form Field, Capture PDF Form Data

VFP8. We are once again looking at editing PDF forms inside of VFP. We are
currently testing the pdf.ocx from Adobe in conjuntion with Gnostice's
pdftoolkit. I have looked at a couple of other options such as iSedQuickPDF.
Right now I am able to open a pdf file using Gnostice's pdftoolkit (the ocx
is slapped on the VFP form) and programmatically populate the pdf formfields
on the pdf form with data from our app using the Gnostice pdftoolkit. We
then save the pdf form to disk and open it again in the form using the
pdf.ocx. The Adobe pdf.ocx allows the user to edit the fields on the
pdfform. If the pdf form is saved to disk, I can then grab the changes to
the formfields on the form using the Gnostice pdftoolkit and save those
changes to tables in our app. 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 any data. Of course, our goal
is to capture the form field data changes and save those changes back to our
app's tables. Since the Adobe ocx is providing the means of displaying and
editing the pdf form fields, the Gnostice pdftoolkit on the form does not
see the pdf form once it is loaded in the Adobe ocx (since it is in memory
and not stored to disk yet after the changes are made) or its values. The
pdf toolkit can only grab the form field valus once the pdf form is saved to
disk again after the changes are done. Then we run into the problem of
requiring the full version of Adobe Acrobat on the workstations so the adobe
pdf.ocx will save the form with the data to disk so the toolkit can read the
changes. Any ideas? We could handle it with purchasing two separate pdf
tools if necessary. If that is the case, then we need a means of displaying
the pdf form and allowing the user the means to edit the form fields on the
pdf form, and then save the data to disk so the 2nd toolkit can readin the
changes.

Thanks for any ideas you may have!
Vita contingit. Vive cum eo.
(Life Happens, Live With it!)

Roger
Sun Oct 24 11:40:05 CDT 2004

Tracy <anonymous@discussions.microsoft.com> wrote:
[snipped background]

>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 any
> data.

Correct. Once upon a time there was the FDF Toolkit. Adobe dropped
that and released Business Tools in its place. Adobe dropped
Business Tools a few months ago and replaced it with something
else (sorry, I can't rememeber what it's called - you can scour
Adobe's website and still draw a blank). All of these required
royalty payments to Adobe on a per-user basis.
Oh ... and then there was a product from an Adobe partner
called Cardiff Software (if I recall correctly). It was quirky and
very expensive.
The bottom line is that Adobe really doesn't want you to be able
to save PDF forms with data without the full version of Acrobat.

>Of course, our goal is to capture the form field data changes
> and save those changes back to our app's tables. Since the Adobe ocx
> is providing the means of displaying and editing the pdf form fields,
> the Gnostice pdftoolkit on the form does not see the pdf form once it
> is loaded in the Adobe ocx (since it is in memory and not stored to
> disk yet after the changes are made) or its values. The pdf toolkit
> can only grab the form field valus once the pdf form is saved to disk
> again after the changes are done. Then we run into the problem of
> requiring the full version of Adobe Acrobat on the workstations so
> the adobe pdf.ocx will save the form with the data to disk so the
> toolkit can read the changes. Any ideas?

Be aware that the sole purpose of the OCX is to enable PDFs to be
displayed in a web browser. Adobe specifically denies support for
any other purpose. Also, if you're running under Win XP, SP2
stimies even this

>We could handle it with
> purchasing two separate pdf tools if necessary. If that is the case,
> then we need a means of displaying the pdf form and allowing the user
> the means to edit the form fields on the pdf form, and then save the
> data to disk so the 2nd toolkit can readin the changes.

The closest I've had experience with is Amyuni's PDF Creator.
www.amiyuni.com
The PDF Creator OCX uses its own form field objects (it doesn't
recognise Acrobat's form fields). The trouble is, with each release,
Amyuni fixes one problem and creates a whole bunch of others.
I'm not recommending this product but it might suit your needs
if you can live with its quirkiness.

> Thanks for any ideas you may have!

I've been developing form-filler applications for the last 12 years
in FoxPro and Delphi. I've tried the PDF route on many occasions
but have run into the same problems that you are currently facing.
Now, I use Word (for document design), PaintShop Pro (to create
background images of the form for VFP), VFP and Crystal Reports.
I can still output forms to PDF but am not reliant on Acrobat for
any of it.

> Vita contingit. Vive cum eo.
> (Life Happens, Live With it!)

Or (more accurately IMO) ...
Excretum contingit
(Shit happens, Live with it) ;-)

--
Roger Ansell
Adelaide, Australia

My real email address is ransell at senet dot com dot au

Roger
Sun Oct 24 11:58:50 CDT 2004

> Or (more accurately IMO) ...
> Excretum contingit

Sorry for my Latin. I meant ...

Excreta contingit

I got confused with my old school motto ..

Semper in excretum (which is of course the ablative
of excreta)

Just to set the record straight, you understand. <g>

--
Roger Ansell
Adelaide, Australia

My real email address is ransell at senet dot com dot au