For the benefit of future googlers (I can't imagine I'm the only person who's had this problem) - lacking an answer, I figured it out myself. iTextSharp *does* store a map of ugly field names to xfa value nodes, which you can access via AcroFields.Xfa.FindDatasetsNode(). However, and I would submit that this is kind of weird behavior for it to be actually useful for multivalued lists, that map contains the individual value elements - which, in the case that you have a multivalued list with nothing selected, means the map doesn't know about the field at all. (I'm idly curious whether there was a good reason for that decision, but anyway, knowing that, it wasn't that hard to get around.) The key was definitely in knowing that itextsharp tries to abstract away the existence of xfa, but that the abstraction breaks in this case. Thus, once again, thanks! -Adam
On Tue, Mar 29, 2011 at 2:45 PM, Adam Field <[email protected]> wrote: > On Mon, Mar 28, 2011 at 12:44 PM, Mark Storer <[email protected]> wrote: >> Ah. You have an XFA based form, and are using AcroForm tech to address it. >> Don't do that. > > Alright, I suppose that's good to know (I do see that now, and also > see it documented that using the high-level AcroForms API *usually* > works, but not always, and that SetListSelection never will). So, it > took a bit of trial and error, but I successfully retrieved the XFA > xml, modified the value of that list field, then put it back, and the > new value showed up in the pdf. But in the case of an arbitrary pdf > where I don't have previous knowledge of what the underlying xml looks > like... this might also be a dumb question, but I don't suppose > there's any way to find the correct value to modify in the xml (if > multiple fields share the same human-readable name) based on the > information about the fields returned from > PdfReader.AcroFields.Fields? Can I even assume that > PdfReader.AcroFields.Fields will always *have* information about the > number and names of fields in an XFA-based form, or should I be > looking elsewhere in that case? (It's always seemed to work so far in > abstracting whether the input was xfa-based or not, but possibly we > were just lucky?) > > But anyway, thanks again for pointing me in the right direction. > -Adam > ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ iText-questions mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/itext-questions iText(R) is a registered trademark of 1T3XT BVBA. Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/ Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php
