LoadXML() geht nicht nach Start durch ShellExecucte()

[nru]

Genau so siehts aus. Zugriffsverletzung und fertig ... mom ... Screenie hängt an.


In c findet sich ein komplett zusammengesetzter xml-String. Mit allem was dazu gehört. Und der wird ja auch perfekt eingelesen, wenn die Anwendung "normal" gestartet wurde. Geschieht das aber wie oben geschildert, dann gibts den GPF.


Gruss
Norbert

[mkinzler]

Mal im Debugger geschaut, wo der Fehler genau auftritt?

[sx2008]

Welche Version von MSXML2 wird denn verwendet?
Meine Erfahrung ist, dass alles unterhalb von MSXML Version 4 SP2 relativ buggy ist.
Ich habe auch schon festgestellt, dass .LoadXML() manchmal Erfolg meldet, obwohl das Dokument nicht geladen wurde.

Delphi-Quellcode:

if fsxml.LoadXML( c ) then begin {Bestehende XML laden}
   // LoadXML() hat True zurückgegeben
   // trotzdem ist fsxml.DocumentElement = nil
   recInsertNodes(fsxml.DocumentElement, cHash ); // und dann knallt es hier
   ...
end;

Evtl. liegt das daran, dass die verknüpfte Schemadatei nicht geladen werden konnte.

[nru]

Zitat von mkinzler:

Mal im Debugger geschaut, wo der Fehler genau auftritt?

Genau in LoadXML().

Zitat:

Welche Version von MSXML2 wird denn verwendet?

Guter Hinweis. Jetzt hab ich das mal aktualisiert. Aber auch mit v6 gibts diesen Fehler in LoadXML().



Ich werd den Verdacht nicht los, dass das Problem irgendwie in Richtung Prozesse, Threads oder ähnliches zu suchen ist. Es wirkt so, als wäre MSXML2 durch den ShellExecute/CreateProcess-Aufruf nicht richtig initialisiert worden. So was in der Art?!

[Luckie]

Findet er die Datei eventuell nicht? Gib mal bei Shellexecute als Arbeitsverzeichnis das Verzeichnis an, wo die XML Datei liegt.

[DeddyH]

Evtl. Leerzeichen im "Parameters"-Parameter von ShellExecute enthalten? Dann wird die Datei nämlich auch nicht gefunden. Das ist aber nur eine Vermutung, Genaueres kann man erst sagen, wenn man den ShellExecute-Aufruf einmal sieht.

[mkinzler]

Oder wird eine andere Version einer benötigten Dll verwendet

[himitsu]

Was passiert, wenn du explizit versuchst eine bestimmte MSXML-Version zu nutzen?

In der Unit msxml gibt es noch Varianten wie CoDOMDocument40, welche dann die Version 4.0 verwendet,
wärend CoDOMDocument versucht das aktuellste zu laden.
Aber Achtung, die verlangte Version muß dann auch installiert sein.

In Windows sind oftmals mehrere Versionen gleichzeitig installiert.
http://www.delphipraxis.net/143611-m...tml#post972480

[nru]

Zitat von Luckie:

Findet er die Datei eventuell nicht? Gib mal bei Shellexecute als Arbeitsverzeichnis das Verzeichnis an, wo die XML Datei liegt.

Es geht um keine Datei! Das ist ein String, der da mit MSXML zerlegt werden soll.
Also Pfade können da keine Rolle spielen.

c wird als const Parameter an die Funktion übergeben, in der LoadXML aufgerufen wird (s.a. erstes Posting).

Und wie schon gesagt, das läuft ja alles glatt durch - wenn die Anwendung über Explorer, Verknüpfung oder IDE gestartet wird. Die ist auch schon seit Monaten genau so im Einsatz. Jetzt aber soll sie aus einer anderen Anwendung aufgerufen werden und somit bin ich leider genau hier gelandet.

Zitat von himitsu:

Was passiert, wenn du explizit versuchst eine bestimmte MSXML-Version zu nutzen?

Immer dasselbe Ergebnis. Da hatte ich mir auch etwas von versprochen. No way.

Gruss
Norbert

[himitsu]

In welcher Codezeile tritt denn nun eigentlich der Fehler auf? (oder hab ich da was übersehn)

sicherheitshalber mal Sowas machen:

Delphi-Quellcode:

fsxml := CoDOMDocument.Create;
if not Assigned(fsxml) then
  raise Exception.Create('es konnte keine XML-Instanz erstellt werden oder MSXML ist nicht installiert');fsxml.async := False;
...