Winword-OLE Search&Replace

[hoika]

Hallo,
ich habe hier eine Docx-Datei mit einer Kopfzeile.
In der Zip-Datei (Docx=Zip, wie ihr ja wisst) steht die Kopfzeile in header2.xml.
Das Ersetzen klappt.
Jetzt habe ich eine weitere Docx-Datei, das steht die Kopfzeile in header3.xml.
Und genau hier klappt das Ersetzen nicht!

Es sieht so aus, als ob ich durch alle Kopfzeilen-Sektions muss.

Der Code ist nichts besonderes, kommt zum Teil von hier
http://www.delphipraxis.net/155216-w...nsertfile.html (#5)

Hm, und während des Schreibens hatte ich die Lösung
Wenn ich in Word eine Kopfzeile einfüge, schreibt er "1. Kopfzeile".
Ich kann also nicht nur einen (eine ) geben.

Deshalb noch mal die Frage:
Es sieht so aus, als ob ich durch alle Kopfzeilen-Sektions muss.

Ah ja, nicht über die SL_Search wundern, dass ist noch ein Anpassung zu
"ersetze Zeichen mit mehr als 255 Zeichen".

Delphi-Quellcode:

      
procedure DBInText_OLE_ReplaceString(const WordApp: OLEVariant;
  const SearchString, ReplaceString: String; const ZusatzLogInfo: String = '');

      WordApp.Selection.Find.ClearFormatting;
      WordApp.Selection.Find.Replacement.ClearFormatting;
      WordApp.Selection.Find.Text:= SL_Search[iString];
      WordApp.Selection.Find.Replacement.Text := SL_Replace[iString];
      WordApp.Selection.Find.Forward := True;
      WordApp.Selection.Find.Wrap := wdFindContinue;
      WordApp.Selection.Find.Format := False;
      WordApp.Selection.Find.MatchCase := False;
      WordApp.Selection.Find.MatchWholeWord := False;
      WordApp.Selection.Find.MatchWildcards := False;
      WordApp.Selection.Find.MatchSoundsLike := False;
      WordApp.Selection.Find.MatchAllWordForms := False;

      //WordApp.Selection.Find.Execute(Replace:= wdReplaceAll);
      iDummy := 0;
      if not WordApp.Selection.Find.Execute(Replace:= wdReplaceAll) then
      begin
        iDummy := 1;
      end;

// Aufruf
// 1. Kopfzeile
//               WordApp.ActiveWindow.ActivePane.View.SeekView:= wdSeekFirstPageHeader;
//               DBInText_OLE_ReplaceString(WordApp, SearchString, ReplaceString, '1. Kopfzeile');

               WordApp.ActiveWindow.ActivePane.View.SeekView:= wdSeekCurrentPageHeader;
               DBInText_OLE_ReplaceString(WordApp, SearchString, ReplaceString, 'Kopfzeile');

               WordApp.ActiveWindow.ActivePane.View.SeekView:= wdSeekMainDocument;
               DBInText_OLE_ReplaceString(WordApp, SearchString, ReplaceString, 'Hauptdokument');

               WordApp.ActiveWindow.ActivePane.View.SeekView:= wdSeekCurrentPageFooter;
               DBInText_OLE_ReplaceString(WordApp, SearchString, ReplaceString, 'Fusszeile');

[hoika]

Hallo,
google ...

http://stackoverflow.com/questions/9...ole-and-delphi

Ich glaube, das ist genau das was ich brauche.

[p80286]

Etwas chaotisch.
Zunächst solltest Du Dich entscheiden ob Du die .DOCX-Datei auseinander nehmen willst, oder ob Du die Änderungen mit Hilfe von OLE durchführen willst. Falls Du Dich für OLE entscheidest, das Worddokument besteht aus mehreren "Objektsamlungen" z.b. Shapes,Sections etc. innerhalb derer Du mit Hilfe von .Range und/oder .Selection eine Auswahl triffst, innerhalb der Du z.B. Suchen, Ersetzen oder Text eingeben kannst. (natürlich auch die Schriftart, fett, Unterstrichen usw.)

Du solltest dafür allerdings ein schlüssiges Konzept haben, da ja auch verschiedene Templates Einfluß auf das Dokument haben. Da könnten einige Änderungen durchaus kontraproduktiv sein.

Gruß
K-H

[Sherlock]

Keine Ahnung warum in dem SO-Link keiner drauf kommt, aber Variant ist in OLE/COM die langsamste Möglichkeit. Lieber solltest Du das Word-Objekt über reguläre COM-Interfaces einbinden. Ich hatte früher (also vor 15 Jahren) mal eine Applikation die sehr viel in Word per Variant wurschtelte, die Performance war grottig, egal wie sehr ich dran rum schraubte. Erst ein bisschen später (nachdem ich das Projekt aufgab) kam mir durch "Eric Harmon COM-Automation in Delphi" insbesondere dieser Teil (vorletzter Absatz auf der Seite) die Erleuchtung. Variants sind nichts für Performance intensive Aufgaben. Ohnehin fährt man besser, wenn man gleich die Interfaces einbindet, der Code wird ja dadurch besser lesbar/wartbar.

Sherlock

[hoika]

Hallo,

die Variants haben den Vorteil, dass sie mit alle Word-Versionen funktionieren,
z.B. wurden in das Open neue Parameter eingeführt.
Da muss man je nach Word-Version was basteln.
Man hat dann also mehrere TLB's.

Ich nehme bei Docx die Datei bereits selber auseinander, um meine zu ersetzenden Kenner zu finden.
Ist ja ne simpel Zip-Datei.
Das OLE benutze ich dann "nur" zum eigentlichen Ersetzen.

Ich habe gestern abend mal angefangen mit,
mit meinem Link rumzuspielen.

Für einen Umstieg auf TWordApplication fehlt mir die Zeit.
Aber ich schaue den Harmon-Link mal an.

Danke

Heiko

[Sherlock]

Zunächst, bevor Du Zeit investierst: Harmon ist nur ein allgemeines COM-Buch für Delphi Entwickler.
Als nächstes sollten neue Versionen kein Problem sein, so lange die alten COM-Objekte weiter existieren, was IMHO bei Word eigentlich immer der Fall war (MS liebt die Abwärtskompatibilität). Neue Schnittstellen werden wie bei Windows selbst mit neuen Libs eingeführt, die alten bleiben bestehen.

Sherlock

[bcvs]

Zitat von hoika:

Ich nehme bei Docx die Datei bereits selber auseinander, um meine zu ersetzenden Kenner zu finden.
Ist ja ne simpel Zip-Datei.
Das OLE benutze ich dann "nur" zum eigentlichen Ersetzen.

Und warum ersetzt du deine Texte dann nicht direkt in der DOCX, wenn du sie eh schon auseinander nimmst?

[hoika]

Hallo,
das habe ich auch schon probiert.
Danach ist öfters die Datei defekt (sagt Word).

Ich glaube, dass liegt am Zippen nach dem Ersetzen.
Passiert aber nicht immer,
also lasse ich es lieber.

[Sherlock]

Nein, ich vermute mal eher, Du machst etwas falsch. Wenn nämlich Word sein eigenes Suchen&Ersetzen nicht ohne den von Dir beschriebenen Fehler erledigen könnte, dann wäre die Kacke mächtig am dampfen. HintergrundInformation: Wenn Du per COM/OLE eine Wordfunktion benutzt, ist das in aller Regel auch die Funktion die Word selbst verwendet.

Ich gehe mittlerweile davon aus, daß Du eine veraltete Schnittstelle verwendest, um auf das Word-Dokument zuzugreifen, dafür spricht, daß es mit docx nicht zurecht kommt, dafür aber mit dem von dir vorbereiteten/entpackten Dokument.

Sherlock

[hoika]

Hallo,
Moment!

Klar kommt die alte Schnittstelle mit dem DOCX klar,
aber ich habe noch keine Funktion gefunden, die mir den Word-Text im Printformat,
also als reinen ASCI-Text zurückgibt.
Somit weiss ich nicht, welche Kenner das aktuelle Word-Dokument besitzt.
Kann ja sein, dass es nur 3 Kenner hat.
Dann muss ich nur 3 mal mein Replace machen.
Ich hatte mal was mit Paragraphs gelesen, das aber nicht hinbekommen.
Da Docx ja reine Text(Xml-)-Dateien sind, suche ich die Kenner einfach direkt per Delphi-Code.

Weist du, wie ich den lesbaren Text einer Worddatei mit Word selber ermittle,
also ohne die Formatierungen und den ganzen Schickschnack?

Wie gesagt:
Es sind 2 Methoden:
1. Ermittle alle Kenner des Dokumentes.
2. Ersetze genau diese Kenner durch die entsprechenden Werte.

PS2:
Ich glaube, das war bei Open-Office, der ganz penibel mit seinen Dateien war.
Ausgepackt, etwas im Text (nicht dem Xml-Strukturen) geändert,
wieder zusammengepackt -> Puff, OO sagt, Datei ungültig.

Heiko