Either I'm doing something very wrong, or the XMLDocument component is a terribly written component. I keep getting Access violation at #ADDRESS Read Of #ADDRESS errors, no explanation just a peek at the CPU showing the error occurs all of the place depending on which test I'm doing. Basically, all I want to do is look at the document, and see if the correct node is one of a list of child nodes, the documents below are very scaled down from what I'm trying to use, but if it isn't working at this scale it isn't gonna work at any.

All attempts to either search for the node with name vtest or check the name of the node that contains the data within vtest result in access violations. All attempts to read nodes any deeper than the top level result in access violations, doing anything with DocumentElement causes access violations, although something with that did work about an hour ago, still, the command was about n1.n2....n8 dots deep, and would only return the same data/access violation pattern as with any other attempt.

The tests below are the results when trying to assign the leftside function to anything, specifically though, i'm adding it to a listbox directly/inline.

What's up with this? It seems like it's capable of doing what I want it to, infact, it seems like its being deliberately malicious :P xml isn't much use if it can't cope with custom tags.

Here's the code from my procedure:

  XMLPath   : String;
  XMLReader : TXMLDocument;
  iNode    : Integer;
  XMLPath   := NetPath + AppendPath + 'version.xml';
  XMLReader := TXMLDocument.Create(nil);
  XMLReader.Active    := True;
  Status.AddItem(**COMMANDSBELOW*, nil);

With document
<?xml version="1.0" encoding="iso-8859-1"?>
Results XMLReader.ChildNodes[1].Text - Returns 'test', all seems good. XMLReader.Node.NodeName - Returns '#document', that isn't anywhere in the document, but ok. XMLReader.ChildNodes[0].NodeName - Returns 'xml', which is the name of the document header, fair enough. XMLReader.ChildNodes[1].NodeName - Access Violation, no explanation of why XMLReader.ChildNodes[2].NodeName - Exception, index (2) is out of bounds, index 2 doesn't exist, so fair enough. XMLReader.ChildNodes.FindNode('xml').Text - as expected; version="1.0" encoding="iso-8859-1" XMLReader.ChildNodes.FindNode('vtest').Text - Access Violation, no explanation of why XMLReader.DocumentElement.XML - Access violation XMLReader.ChildNodes[0].XML - <?xml version="1.0" encoding="iso-8859-1"?> XMLReader.ChildNodes[1].XML - Access violation

And With document
<?xml version="1.0" encoding="iso-8859-1"?>
Results XMLReader.ChildNodes[1].ChildNodes[0].Text - Access Violation

Recommended Answers

All 4 Replies

The solution was to put an instance of the XMLDocument object on my form at design time.. Not perfect because I have to reuse it for an exponential number of XML documents, and now I have to think carefully about forking/threads.

I can't understand the problem in my code, if it wasn't working atall that would make more sense, but sortof working is much more confusing. I'm gonna check the properties of the standard dropped-on-form XMLDocument and a runtime constructed XMLDocument later, for now though I'm hoping I have the order of operations right to avoid instance corruption.

Has anyone else experienced similar outcomes when using XMLDocument components created at runtime?


Delphi's TXMLDocument class isn't coded by Borland but is a wrapper to MSXML COM object. You might try "XMLReader := TXMLDocument.Create(self);" or if the code isn't in a method of the form then "XMLReader := TXMLDocument.Create(Form1);" this will make the owner (responsible for memory dispose) of the created component your form.

Loren Soth

well, that seems to work, i'm still reusing objects 'cos my code structure's like that now, but now they're runtime objects. Interesting tho, Seems that Delphi's garbage collection is quite rough so I should probably do the polite thing and clean-up in the next version.

with re. to TXMLDocument, if it wraps MSXML, is it portable? (i.e. will a program that uses it work on Linux?)



Unmanaged (non .Net) Delphi (Delphi 7 and below) has no automatic garbage collection at all. If you are referring to COM objects automatic disposing when ref count reaches zero, the instancess of COM classes you use to access in Delphi are just delphi wrapper classes which still require manual freeing.
COM is a proprietary MS technology and COM objects work only on Windows platform.

Loren Soth

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.