Saxon

Legacy ID: #5635935 Legacy Poster: riko (reksteen)

(apologies didn't complete previous message, hit Enter accidentally) I am able to reproduce the problem by changing the DomDestination in Example.cs in the resources to TextWriterDestination. Here is the stack trace (from the example): ===== XsltUsingResultHandler ======= Test failed unexpectedly: Object reference not set to an instance of an object. at net.sf.saxon.Controller.transform(Source source, Result result) at Saxon.Api.XsltTransformer.Run(XmlDestination destination) at XsltUsingResultHandler.run(Uri samplesDir) at Examples.Main(String[] argv) I am using DomDestination in the meanwhile, but would ideally like to use TextWriterDestination, because an XmlWriter is supposedly more efficient if you just want the xml as a string. (The IResultDocumentHandler interface is really cool btw).

Legacy ID: #5636770 Legacy Poster: Michael Kay (mhkay)

Thanks for reporting this. The null pointer exception is happening during the call on Close(), seemingly because the Result object can't be found in the list of destinations that have been opened. I'm investigating - I think it must be something to do with the HashCode of the result object changing when it is written to. Are you sure you need an XmlTextWriter as your destination? If you are just serializing, it would be better to use a Saxon.Api.Serializer - that way it would take account of all the XSLT-defined xsl:output properties, which the XmlTextWriter serializer knows nothing about.

Legacy ID: #5641480 Legacy Poster: riko (reksteen)

Good point. I should be using Serializer instead of XmlWriter. I used TextWriterDestination simply because I had a method that already took an XmlReader as input and XmlWriter as output, so it was easiest to just wrap the XmlWriter with a TextWriterDestination. The same error in IResultDocumentHandler occurs if I use a Serializer together with a StringWriter, by the way. I'm going to try using a MemoryStream, or stick to using a DomDestination for now.

Legacy ID: #5642200 Legacy Poster: Michael Kay (mhkay)

I've isolated the problem and a source patch is now in Subversion. (Module xslt.cs) See https://sourceforge.net/tracker2/?func=detail&aid=2283963&group_id=29872&atid=397617 Thanks for reporting it.