LoadXML() geht nicht nach Start durch ShellExecucte()

[nru]

Hallo zusammen,

eine Anwendung beinhaltet folgende Funktion zum Lesen eines XML-formatierten Strings

Delphi-Quellcode:

function TMDLizenz.CalcCheckSumFromString(const c:String): String;
var
   fsxml: IXMLDOMDocument2;
   cHash: String;
begin

   result := '';
   fsxml  := CoDOMDocument.Create;
   fsxml.async := False;
   
   if fsxml.LoadXML( c ) then begin                   {Bestehende XML laden}
      recInsertNodes(fsxml.DocumentElement, cHash );  {String für SignaturHash rekursiv erstellen}
      result := self.DoSignatureLicense( cHash );     {MD5Hash über gesamte Lizenz erstellen}
   end;

   fsxml := nil;

end;

Funktioniert alles wunderbar und so, wie's soll.

Aber wird diese XML-lesende Anwendung über ShellExecute aus einem anderen Prog. heraus aufgerufen (oder auch über CreateProcess, macht keinen Unterschied) und kommt dann an LoadXML(), fliegt mir alles zugriffsverletzt um die Ohren. Warum ist das so? Der String c ist in beiden Fällen identisch.

Dank und Gruß
Norbert

[mkinzler]

Zitat:

fliegt mir alles zugriffsverletzt um die Ohren.

Etwas mehr Details wären vielleicht hilfreich.

[himitsu]

Was steht in

Delphi-Quellcode:

c

?

Ich vermute jetzt einfach mal, daß du in

Delphi-Quellcode:

c

einen absoluten Pfadnamen übergeben solltest und keinen Relativen. :glaskugel:

[implementation]

Zitat:

Zitat von mkinzler (Beitrag 1095461)

Zitat:

fliegt mir alles zugriffsverletzt um die Ohren.

Etwas mehr Details wären vielleicht hilfreich.

Was soll er denn noch nennen? Bei LoadXML tritt bei ihm eine EAccessViolation auf.

[ot]Aber die Formulierung ist geil :lol:[/ot]

[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:

Zitat von mkinzler (Beitrag 1095484)

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:

Zitat von Luckie (Beitrag 1095530)

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:

Zitat von himitsu (Beitrag 1095535)

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;
...

[nru]

Zitat:

Zitat von himitsu (Beitrag 1095544)

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

In der weiteren Vearbeitung nach LoadXML(). Zugegeben, Version 1 war nicht sonderlich gut abgesichert. :? Deshalb dann auch die Zugriffsverletzung. Aber das Problem, dass LoadXML nicht einliest, bleibt. Ich hab jetzt Deinen Tip mit Assigned() mal eingbunden. Also NIL ist es nicht. Und somit komm ich auch nicht an das raise. Aber der dann folgenden Aufruf von LoadXML() klemmt und gibt false zurück.

Sieht jetzt so aus:

Delphi-Quellcode:

function TMDLizenz.CalcCheckSumFromString(const c:String): String;
var
   fsxml: IXMLDOMDocument2;
   cHash: String;
begin

   result := '';
   fsxml  := CoDOMDocument.Create;

   if not Assigned( fsxml ) then
      raise Exception.Create( 'Es konnte keine XML-Instanz erstellt werden' );

   fsxml.async := False;

   if fsxml.LoadXML( c ) then begin                   {XML-String laden}
      recInsertNodes(fsxml.DocumentElement, cHash );  {String für SignaturHash rekursiv erstellen}
      result := self.DoSignatureLicense( cHash );     {MD5Hash über gesamte Lizenz erstellen}
   end;

   fsxml := nil;

end;

[himitsu]

Irgendwie sollte man aus dem fsxml auch eine Fehlermeldung/Fehlercode auslesen können, also warum es beim LoadXML nicht klappte.

[nru]

Zitat:

Zitat von himitsu (Beitrag 1095552)

Irgendwie sollte man aus dem fsxml auch eine Fehlermeldung/Fehlercode auslesen können, also warum es beim LoadXML nicht klappte.

Und genau das hab ich dann jetzt auch mal versucht. Und siehe da ... bin auch fündig geworden.
Vielen Dank für den Denkanstoß.

Delphi-Quellcode:

         
...
   fserr := fsxml.parseError;
   raise Exception.Create( 'Es konnte keine XML-Instanz erstellt werden: ' + #10#13 +
                            fserr.reason + #10#13 + fserr.srcText);

Und jetzt zur peinlichen Seites dieses Postings ... die ZV kam gar nicht aus LoadXML, hatte sogar überhaupt nichts mit dem XML-Bereich zu tun. :( Das war eine nachgelagerte Problematik in der späteren Verarbeitung der XML, und ist mir leider anfangs überhaupt nicht aufgefallen. Bis ich über das Errorhandling der XML mich dann so langsam aber sicher nach oben gearbeitet habe :wink:

Hatte tendentiell dann doch schon mit dem Aufruftyp (als über ShellExecute und somit mit den hier schonmal angesprochen Pfaden zu tun). Genauer gesagt mit fehlenden Pfadangaben, die dann bei Aufruf über ShellExcute dann zum Problem führten.

Habt vielen Dank für Eure Ideen! :thumb:


Gruss
Norbert