•
•
•
•
What is DaniWeb IT Discussion Community?
You're currently browsing the Pascal and Delphi section within the Software Development category of DaniWeb, a massive community of 370,597 software developers, web developers, Internet marketers, and tech gurus who are all enthusiastic about making contacts, networking, and learning from each other. In fact, there are 2,026 IT professionals currently interacting right now! Registration is free, only takes a minute and lets you enjoy all of the interactive features of the site.
Please support our Pascal and Delphi advertiser:
Views: 6105 | Replies: 4 | Solved
 |
•
•
Join Date: Jul 2006
Location: Deptford, London
Posts: 916
Reputation: 
Rep Power: 5
Solved Threads: 46
Posting Shark
XMLDocument - Eeek 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
xml isn't much use if it can't cope with custom tags.
Here's the code from my procedure:
With document
<?xml version="1.0" encoding="iso-8859-1"?>
<vtest>test</vtest>
Results
And With document
<?xml version="1.0" encoding="iso-8859-1"?>
<vtest><vtest2>test<vtest2></vtest>
Results
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
xml isn't much use if it can't cope with custom tags.Here's the code from my procedure:
var XMLPath : String; XMLReader : TXMLDocument; iNode : Integer; begin XMLPath := NetPath + AppendPath + 'version.xml'; XMLReader := TXMLDocument.Create(nil); XMLReader.LoadFromFile(XMLPath); XMLReader.Active := True; Status.AddItem(**COMMANDSBELOW*, nil); end;
With document
<?xml version="1.0" encoding="iso-8859-1"?>
<vtest>test</vtest>
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 whyXMLReader.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 whyXMLReader.DocumentElement.XML - Access violationXMLReader.ChildNodes[0].XML - <?xml version="1.0" encoding="iso-8859-1"?>XMLReader.ChildNodes[1].XML - Access violationAnd With document
<?xml version="1.0" encoding="iso-8859-1"?>
<vtest><vtest2>test<vtest2></vtest>
Results
XMLReader.ChildNodes[1].ChildNodes[0].Text - Access Violation 
•
•
Join Date: Jul 2006
Location: Deptford, London
Posts: 916
Reputation:
Rep Power: 5
Solved Threads: 46
Posting Shark
Re: XMLDocument - Eeek 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?
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?
•
•
Join Date: Mar 2006
Posts: 219
Reputation:
Rep Power: 3
Solved Threads: 2
Posting Whiz in Training
Hi,
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
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
Crimson K. Software _________________________________________________________________ Crimson K. Blog
•
•
Join Date: Jul 2006
Location: Deptford, London
Posts: 916
Reputation:
Rep Power: 5
Solved Threads: 46
Posting Shark
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?)
Matt
with re. to TXMLDocument, if it wraps MSXML, is it portable? (i.e. will a program that uses it work on Linux?)
Matt
If it only works in Internet Explorer; it doesn't work.
•
•
Join Date: Mar 2006
Posts: 219
Reputation:
Rep Power: 3
Solved Threads: 2
Posting Whiz in Training
Hi,
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
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
Crimson K. Software _________________________________________________________________ Crimson K. Blog
|
•
•
•
•
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
•
•
•
•
•
•
•
•
DaniWeb Pascal and Delphi Marketplace
Linear Mode
Similar Threads
- Power Saving Enable (Windows NT / 2000 / XP / 2003)
- I need a project ;P (C++)
- Dealing With XML in Visual C++ (C++)
- bridge yet again (Viruses, Spyware and other Nasties)
Other Threads in the Pascal and Delphi Forum
- Previous Thread: Convert to hex
- Next Thread: Hide Delphi's Splash screen - Delphi 7
