Just to be sure of a few things...
Which version of Xerces are you using?
>> table.removeChild(row);
The node "row" is going out of scope or being set to NULL after
this, right?
It appears as though cloneNode() goes through all the right
gyrations. I'm not entirely convinced that a node
Modified the code as follows:
> Code snippet begins here:
>
> DOM_Element row = thePage.getElementById("template");
row.removeAttribute("id");
DOM_Element cell1 = thePage.getElementById("cell1");
cell1.removeAttribute("id");
DOM_Element cell2 = thePage.getE
One piece I cut out was a bit of code to go through the cloned tree and
remove all "id" attributes. However, this didn't appear to make much
difference. I'll make a few changes to get rid of the duplicated "id"
attributes and see if it changes things.
Thanks
-Evan
-Original Message-
Fr
On Friday, April 13, 2001, at 11:33 AM, Day, Evan wrote:
> Code snippet begins here:
>
> DOM_Element row = thePage.getElementById("template");
>
> DOM_Node table = user_row.getParentNode();
>
> for(int i = 0; i < len; i++) {
>
> setTextById("cell1", cell1_da
I've done a fair bit of research on Xerces-C and how it manages memory, and
I understand that it uses reference counting to determine when it needs to
free up objects. I'm having a bit of a problem, however...
In C++, I'm using a DOMParser to read in an XHTML file, do a
DOMParser::getDocument()
On Mon, 9 Apr 2001, Tinny Ng wrote:
> Just wanna to give you an update on our Schema Development progress.
> Khaled Noaman, Pei Yong Zhang, and I have been working hard in the
> past couple of months to port the Schema Support in Xerces-J to
> Xerces-C, and everything is still on track right no
"Dean Roddey" <[EMAIL PROTECTED]> writes:
> Ok, I now finally get to ask a question... We are probably going to
> use Xerces stuff at work, and some of the folks involved need to use
> Perl interfaces. What is the state of the state with the Perl stuff
> now in the repository vs. what's in the cu
