>From the readme.html files, I find this:
Xalan 1.4 -> Xerces 2.1
Xalan 1.3 -> Xerces 1.6
I agree, having a compatibility table in the archive directories of
both Xerces and Xalan would be a nice thing.
You seem to be at an "in-between" version, so you'd probably need to
change the Xerces version
Not really a Xalan-C problem, but here's my answer:
Buy Michael Kay's Programmer Reference.
Don't know if this URL will make it through the listserver, but you can
find it at Amazon, among others.
http://www.amazon.com/exec/obidos/tg/detail/-/0764543814/qid=1094171973/sr=8-1/ref=sr_8_xs_ap_i1_xgl
You have to use entities in the script, like > instead of the ">"
characters, unless you wrap it it in
I don't know about compatible. Here's where the archives are:
http://archive.apache.org/dist/xml/xalan-c/
The tested versions were Xalan 1.3 + Xerces 1.6, and Xalan 1.4 + Xerces 2.1. You might be able to roll back to Xerces 1.6 with minimal impact (just guessing). Going forward is a bit more
This is what I suspected. It definitely won't work. You need to build the DLLs and app with the same version of Visual Studio. Like I said, I had no success with VC7 a while back and have not tried to upgrade. VS.NET still shuts down on me unexpectedly from time to time and tries to send error
Ryan,
No, I don't think it's VC7. You can't do what XalanDOMString::transcode is trying to do - return memory allocated in one heap (the DLLs) and have it released in the EXE's space. Bad idea. I've got a simple test DLL & EXE that confirms this. It crashes whether built with VC6 or VC7.
Keit
Ryan's compiler options looked Ok (in the first posting) for a debug build. If the right library is being linked, it *should* work.
Ryan, what compiler are you building the app with? I know when I tried to use a VC7-built app with the VC6 built DLLs (that was Xerces 2.2, Xalan 1.5, as I recall
osoft APIs that do that conversion, or you can pretty easily write your own (what I did).Keith Rogers <[EMAIL PROTECTED]> wrote:
I've got a fair amount of code that uses the XalanDOMString::c_str() to create std::string objects,...
I've got a fair amount of code that uses the XalanDOMString::c_str() to create std::string objects, and all linking is with runtime DLLs. I haven't seen a crash. What are you doing, exactly? You can't actually push a char[] array into a vector unless you've got it wrapped in a class that has cop
Actually, David, it did apply - if you think you've got UTF-8, but really don't then the output won't be what you expect.
We're just talking semantics here. I've had a [u]string class (for about 4 years now) that encapsulates both UTF-8 and UTF-16, because it seemed like the X/X transcoders leak
No question - XMLSpy. Been using it for about 3 1/2 years. You need a Unicode font installed, of course.
Don't know if this is your problem, but what happens in Windows UTF-8, e.g., in Notepad, is that the file starts with the UTF-8 encoding bytes (actually, UTF-16 flags FFFE or FEFF encoded as
All of our file XML is UTF-8 input, and I haven't seen any problems with direct file transforms using Xerces 1.6/Xalan 1.3 or Xerces 2.3/Xalan 1.6. I never saw a reason for ICU, since all of our stuff is UTF-8 (or UTF-16), so don't build with it. Like I said, the only time I saw (what should have
Not sure what statement you're having the problem with, but if you've got xsl:output's charset set to UTF-8, and using disable-output-escaping="yes" (e.g., in xsl:value-of or xsl:text), and still see it, then when I've seen this problem, iti turned out that the data wasn't actually UTF-8.
This ju
Using an XPath _expression_, how can I get a XalanNode that can be updated? It seems like the resulting nodelist has nodes which are all read-only; i.e., setValue(), setNodeValue(), et al, throw XalanDOMException(NO_MODIFICATION_ALLOWED_ERR).
I'm trying to convert a sizable (MS-parser-based) ap
14 matches
Mail list logo
