>That's a scary thought! We went through so many trials and errors and finally found a couple of ways that worked. The only issue is that the final means that we settled on requires a third party tool - however they do have a trial version that can be downloaded and used for testing (which is how we finally decided to go that route when the testing proved successful). It made the entire process so much less time consuming when there a lot of forms to do this way. The means of doing it by creating the .xfdf file (which is actually an xml file) works too though. There is actually another means which is even more common I think which is creating an .xdf file which is not an xml file but Adobe's file structure for reading data for a form... a lot to be included in an article I think!

Yes, you've done a lot of research, which deserves to be shared with the fellow UTrs to save them grief and money. BTW, I'd like to send you some text for quick review. Can I use your e-mail by clicking on the envelope?

>
>>Hi Tracy,
>>
>>Sounds like a material for an article... You can publish it in UT Mag, for example.
>>
>>>Just for information, when we started doing this ourselves we went through a few different methods before we settled on our current process. The pdf forms are provided to us and we add the fillable fields to the form. The forms are industry standard forms created by an approved outside source (ACORD). We put the fillable fields on the forms using Adobe Acrobat.
>>>
>>>Our issue was getting the data from our vfp app into the fields on the already approved pdf form and then allow the user to edit the data if required and save it back to our vfp app and also print the pdf form with the data in the pdf form fields from our app.
>>>
>>>Initially, we created .xfdf files programmatically in vfp that contained the data for the form fields. This worked rather well, but the .xfdf file had to be programmed for each form so it could be created on the fly. We created a table that contained all of the xml tags for each pdf form and we stepped though it when the .xfdf file was generated. We launched Adobe Reader to allow the user to view and print the actual pdf form. This worked well, but as there are over 400 forms anytime the field layout on the pdf form is changed in Adobe Acrobat (because legally the form changes based on state guidelines and regulations) then the table had to be modified so the xml layout would correspond.
>>>
>>>We have since changed to do it differently.
>>>
>>>We have a vfp form for every pdf form. The user enters or modifies data using our vfp form. Each control on the data entry vfp form has a memory variable in the control source property and a value in the TAG property. The value in the tag property matches the field name on the pdf form. We have a cross reference table that contains the memory variable or table fieldname and the correcponding pdf form field name assigned when the form field was added to the pdf form in Acrobat (the same as in the tag property). by the way, the formfield names in Adobe Acrobat are case sensitive. Most of the data used on the pdf forms is already maintained in our app anyway so this made the most logic and it also made it very easy to save changes back to our app.
>>>
>>>When the user clicks on a print button on the vfp data entry form, our app launches another vfp form that contains the web browser activex control. The pdf form is displayed in the webbrowser control inside the vfp form. Another print button exists on the pdf viewer form that actually prints the pdf form and displays the Adobe print preferences window.
>>>
>>>To get the data from vfp to the pdf form itself, we now use the gnostice pdf toolkit. It works well for our purpose. When the vfp form loads, we step through each control on the vfp form and search for the tag property's value in our cross reference table. If it finds a match then the value is determined by the memory variable or table field in the crosf reference table. If a match is not found, then the value is taken strictly from the control source property. The user modifies the values as necessary on the vfp form and saves the data to our backend as typical in a vfp app. When the user clicks on print, we step through the controls on the form again (to read the tag property which matches a form field on the pdf form) and the gnostice control allows us to assign values to each pdf form field by searching the gnostice object for the pdf form field name. The pdf form is then created on the fly (we store the pdf form itself in a table's memo field) and deleted when the vfp form
>>>is closed.
>>>
>>>Hope this gives you some ideas.
>>>
>>>Tracy