![]() |
WordApplication statt OLE
Hallo Leute!
Ich versuche gerade meine Anwendung von Delphi 2.0 auf Delphi 7.0 umzustellen. Die meiste Arbeit machen die leider sehr zahlreichen Berichte (QuickReport). Aber das ist nur Arbiet und nicht meine eigentliches Problem. Das Problem ist, das Word immer ein Fenster zur Bestätigung des Zeichensatzes aufpoppt, das hatte aber unter D2 mit OLE schon funktionierte. Ich benutze jetzt die WordApplication-Komponente. Mein Programm schreibt Semikolon-separierte Steuerdateien, welche ich im Anschluss mit dem entsprechenden Serienbrief vorm Programm her aufrufe. Leider ist Word ja mit jeder Version (ich nutze Word 2003) schlauer geworden und macht hier eine Zeichensatzerkennung für meine Steuerdatei. Bei meine alten Variante hat Word das Bestätigungsfenster einfach übergangen und einfach den Zeichensatz genommen, den es erkannt hat. Das war fatal, habe ich aber dadurch behoben, das ich meine Steuerdateien in Unicode schreibe und somit passte es fortan. Jetzt jedoch, mit der WordApplication-Komponente, blendet Word wieder genau dieses Fenster auf, erkennt auch richtig Unicode, und so sollte dann alles automatisch ablaufen. Nur das Fenster dürfte nicht erscheinen Gib es da irgendeinen Parameter, den ich beim Öffnen oder Starten des Serienbriefes setzten kann, damit Word nicht mehr nachfragt. Falls einer eine Idee hat, schon mal vielen Dank. Gruss |
Re: WordApplication statt OLE
Moin Micha,
welche Kodierung hat die Datei - UTF8 oder UTF16? Hast du ein Byte-Order-Mark geschrieben? Ich habe zwar kein Word zum Testen, aber ich vermute, dass die Kodierung durch Textanalyse geschieht und deshalb eine Rückfrage stattfindet. Bei einem BOM dürfte für Word kein Zweifel bestehen und der Dialog könnte entfallen. Freundliche Grüße |
Re: WordApplication statt OLE
Zitat:
Den Programmcode für das Unicode-Schreiben, habe ich damals auch hier aus der Delphi-Praxis bekommen:
Delphi-Quellcode:
Und es sieht so aus (habe etwas Probleme, das mit den Zeigern richtig zu verstehen, deswegen habe ich gleich die Funktion hier gepostet, damit nichts falsches erzähle ) als wird auch ein BOM geschrieben.
function TSteuerdatei.SaveAsUnicode: Boolean;
var data: String; fs: TFileStream; b, buffer: ^Word; size: Integer; i: Integer; begin data := AufbereitenAusgabe; size := (Length(data)+1) * 2; GetMem(buffer, size); try b := buffer; b^ := $FEFF; //BOM = Byte Order Mark inc(b); //string copieren for i := 1 to Length(data) do begin b^ := ord(data[i]); inc(b); end; //FileStream schreiben fs := TFileStream.Create(FPfadDateiName, fmCreate); try fs.WriteBuffer(buffer^, size); finally fs.Free; end; FFeldListe.Clear; Result := True; finally FreeMem(buffer); end; end; Hatte ja auch mit OLE so funktioniert. Ich habe halt gedacht, das ich beim Word anschubsen, über die WordApplication-Komponente, noch einen Parameter setzen muss. Gruss |
Re: WordApplication statt OLE
Hallo Micha,
erste Wahl für das Arbeiten mit Delimited Text Files als Steuerdateien für die MailMerge-Funktion von MS Word 2003 scheinen mir ODC-Dateien in Verbindung mit einer Konfigurationsdatei namens Schema.ini zu sein. Leider habe ich keinen direkten Zugriff auf die entsprechende Dokumentation - den solltest aber du haben, oder? Die ODC-Datei erzeugst du mit MS Office und die Datei Schema.ini erstellst du mit deinem Editor.
Code:
Du kannst für jede Steuerdatei einen eigenen Abschnitt in der Datei Schema.ini anlegen. 65001 ist die CodePage von UTF8. Wenn deine Feldbezeichner in der ersten Zeile der Steuerdatei stehen, dann entfallen die Angaben zu Col1..Col255 und du verwendest ColNameHeader=True. Hinter den Feldbezeichnern kannst du einen Datentyp vorgeben, damit Word nicht unnötig (falsch) raten muss. MaxScanRows beschränkt die Datenanalyse, damit alles ein wenig schneller geht.
[deine-steuerdatei.txt]
Format=Delimited(;) MaxScanRows=25 CharacterSet=65001 ColNameHeader=False Col1=Postleitzahl text Col2=Nachname text Jetzt hilft nur noch ein beherzter Griff zum Handbuch. Freundliche Grüße |
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:24 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz