Hi Alberto,
I'm not really sure if const_cast is so safe. Apparently, setting user
data (and modfying whatever tables Xerces uses to store it) while in a
DataHandler confuses Xerces so that it eventually crashes. At least from
what I can see it seems to invalidate the enumerator that Xerces uses to
iterate over its data handlers in DOMDocumentImpl::callUserDataHandlers().
Does Xerces 3.0 approach this in a different way, or is the signature
the only thing that changed? Because in the latter case, I suppose
switching to 3.0 won't solve my problem either.
Cheers,
Uwe
Alberto Massari amassari-at-datadirect.com |xerces-c-users mailing list|
schrieb:
Hi Uwe,
actually there is a bug open for the "const" issue, that has been
fixed in the 3.0 release (as it requires a signature change). In
version 2.7 you have to use const_cast, but don't worry, it's safe...
Alberto
At 16.59 05/02/2007 +0100, [EMAIL PROTECTED] wrote:
Thanks Alberto,
The workaround does the trick. Hoever, I've got another problem at my
hands now, which I suspected to come to me beforehand (but I never
got that far before..): Since both the src and dst DOMNode arguments
of DataHandler::handle() are const, I cant attach user data to the
new node that's created by importNode().
At first I hoped that Xerces would implicitely copy the user data
pointer from src to dst, while giving the DataHandler a chance to fix
what could become a mess, but apparently this is not so.
Is there a proper way to get the user data from one node to another?
I can use const_cast<>, but that's surely not as things are intended
to be is it?
Cheers,
Uwe
Alberto Massari amassari-at-datadirect.com |xerces-c-users mailing
list| schrieb:
At 11.49 05/02/2007 +0100, [EMAIL PROTECTED] wrote:
Hi Alberto,
Thanks a lot for the reply!
I've resolved the debugging issue now; apparently the DLL was older
than the PDB, which doesn't help...
So now I can debug into Xerces, and I traced the importNode() call
to DOMDocumentImpl::callUserDataHandlers(), where it enumerates
over the user data table. However, userDataEnum.hasMoreElements()
returns false on the first iteration, which apparently means that
there are no handlers, am I correct? But as I said, my handler does
get called when I delete nodes...
Do you have any more clues?
If I read the code right, the handler for importing nodes must be
registered on the DOMDocument itself, so you can workaround the
problem by registering the handler there; but by reading the specs
this is wrong, as "the application can provide a handler that gets
called when the node the object is associated to is being cloned,
imported, or renamed". Unless someone else has problems with this,
I'm going to fix this for 3.0.
Alberto
Cheers,
Uwe
Alberto Massari amassari-at-datadirect.com |xerces-c-users mailing
list| schrieb:
At 01.09 03/02/2007 +0100, you wrote:
Hello,
I overrid XercesDOMParser's startElement() method to attach user
data to each newly created DOMNode. This works fine, and I can
retreive the data later with getUserData().
However, I now merge two documents into one DOM, and I use
importNode() for copying the nodes into the main document,
collecting the nodes in a DocumentFragment first, and then adding
them to the main document with replaceChild().
a) The new nodes in the main document don't have the user data
any more;
b) The data handler is not called while executing importNode().
However, it _is_ called when I delete the parser, when all nodes
it owns are deleted, which means that it should be properly
registered.
Any clues what I could have done wrong here? I Use Xerces 2.7.0.
Uwe,
the code for importNode calls the NODE_IMPORTED handler (unless
you are cloning the entire document); can you verify if it invoked?
Cheers,
Uwe
P.S.: For some odd reason I never manage to debug into Xerces
from my application on my Windows XP/VS7.1 installation, although
the PDB and sources should be accessible; I compiled Xerces
myself. Does anyone have experience with this?
Is the PDB in the same folder of the Xerces DLL being loaded?
Alberto
