I am using the 6.2.1 trial version of PDFNet Java library as well as a licensed earlier version (not exactly sure what but at least a year or two old). Both exhibit the same behavior.
Basically what I am noticing is that a simple update to a text field and a save of a document my datetime fields are no longer looking like datetime fields? That is they seem to be converted to text fields perhaps as they have no date/time picker available on them any longer. When I load the PDF with LiveCycle the fields show as text and not datetime.
NOTE, I am not even updating these datetime fields but just any other text field of the document.
Also, looking at the header of the document, the original shows %PDF-1.6% while the one saved through PDFDoc shows %PDF-1.5%. I am wondering if this has something to do with the issue as well. Is there a way for PDFNet to save in v1.6?
The Adoeb LiveCycle “Save as Static Form” option creates a parallel AcroForm fields setup, parrallel to Adobe’s proprietary XFA fields. When you use PDFNet’s Field class methods, these are interacting with the AcroForm, and not the XFA (which is in embedded xml in the PDF). LiveCycle sets up some sort of connection between the XFA and AcroForm fields.
The key word in the Adobe LieCycle option is the word Static. I don’t think these are meant to be modified other than by someone filling out the fields.
One of the reasons they introduced the idea of Static Fields, is that Adobes own mobile reader software (iOS, Android) can’t handle XFA.
The particular issue that you encountered is that Field.RefreshAppearance will break the implicit connections to the XFA data, so the XFA entry is removed.
You can rename the XFA entry, change the fields, and then restore afterwards.
doc.GetAcroForm().Rename("XFA","XFA_TEMP");
However, this might break the link still. You would then have to modify the XFA XML to change the corresponding value entry in the XFA. See our forums on how to get the XML from XFA.