Paul, Jim,

I've been thinking about taking this approach with some yet-to-be-developed web-based data entry forms. Any known issues with this approach other than to save the data permanently upon a print request so as to avoid 'spoofing' of form information? Having the data on the back end is fine from our pov.

Oh.. What about the licensing issues?

Paul, it sounds like you've done this a little. Do you use Adobe or Amyuni's stuff or ??.

Thanks!!




>>I have been to the Adobe Acrobat site and find references to "fill-in" forms in the feature set for version 5.0.
>>
>>However, there is hardly more than a mention of that phrase.
>>
>>Does anyone know what they mean by "fill-in forms"? For instance, I would expect such a form to be one where the formatting is (basically) fixed and there are areas/boxes/cells/check-boxes, etc that the reader (person) can type into. I would expect the free Acrobat Reader to support this and to have the capability to save/send the (reader) completed form back whence it came (or to wherever).
>
>Yes, it lets you do exactly that. You will find, however, that saving the data isn't quite as simple as you think it should be. If you are "saving" the info to a website (eg. you have a button that posts the info back to a website), it is pretty easy. It works like just an HTML form posting data to a site. If you need to save this information locally, they make you jump through a lot hoops. The user has to "Export" the data to a file manually via a menu item (and they have to select the directory and name it) - no nice interfaces are available.
>
>The data itself is stored in what they call "FDF" files (which is just a specially formatted text file), or you can save in the XFDF format, which looks like XML. The XFDF format is much easier to parse, so I'd suggest using it instead of FDFs. The basic Reader (the free one) has a bunch of limitations that seem to be put their so you'll have to upgrade to the full version. If your plan is to automate them in any way from VFP app, you'll probably want (and need) the full version of Acrobat.
>
>>
>>In addition, given that I can make such forms using WordXX, does anyone know if this is, in fact, what the Adobe product uses to accomplish this? If so, what are the implications of 'named' entry areas, calculation "macros", etc on such Adobe-rendered/completed forms?
>>
>
> You can embed JavaScript into your formst to handle calculations, validation, etc. Not sure what you mean by "what the Adobe product uses to accomplish this". It uses the PDF file format and the Acrobat Reader. Since the reader is free, your users don't need Word. Most gov't agencies are using this technology for their forms, and making them available on the web. You can create your basic form in Word, Publisher, whatever, print it to a PDF via Acrobat, then open the PDF and add the fields to the form.