Office-Dokumente erzeugen: Automatisierung oder nicht?

[jaenicke]

Für .NET gibt es ja ziemlich viele Bibliotheken. Native Bibliotheken gibt es weniger. Ich kenne diese:
https://www.axolot.com/docx.htm
Das ist zwar schon eine Weile her, aber die hat mir gute Dienste geleistet. Und es gibt sie auch für Delphi 10.4.

Die Ansteuerung der installierten Version funktioniert zwar auch prinzipiell, aber damit hatte ich auch immer wieder Probleme.

[juergen]

Für native Erstellung/Lesen von Exceldateien mit 100% Delphicode kann ich folgendes empfehlen. https://www.axolot.com/xls.htm

Ich muss relativ viele Exceldateien erstellen/ lesen, ohne ein installiertes Excel.
Das ist schon meine 2. Bibliothek, die aber restlos meine Ansprüche erfüllt.
Die Handhabung ist wirklich sehr gut und man kommt auch schnell damit klar.
Auch für Word gibt es eine Bibliothek, aber da hab ich keine Erfaung.

[zeras]

Ich nutze auch TMS AdvStrinGrid Import/Export für diverse Programme.
Dazu habe ich aber noch flexcel in Nutzung. Damit manipuliere ich Exceldateien, die vom Kunden erstellt sind. Somit hat man die Möglichkeit, dass der Kunde sein Layout nutzen kann und das Programm dann "nur" noch Daten hinterlegt, die dann mit Verweisen genutzt werden.
Mit Word habe ich leider keine Erfahrungen.

[jobo]

Für Excel Exporte mit Macros und nachgeschalteter Weiterverarbeitung der Exportdaten haben wir mit COM Server gearbeitet. Ging gut, läuft glaube ich immer noch irgendwo. Ebenso Word über COM Steuerung zum Seriendruck. Die Logik war hier, dass der Kunde mit minimalen Kenntnissen Briefe gestalten können sollte und das dann die Templates für den Seriendruck waren. Hierzu wurde nicht die Seriendruckfunktion verwendet, sondern Textmarken im Template programmatisch befüllt. Durch die API konnte man auch relativ einfach den Prozess kontrollieren, ob Layoutfehler auftraten (Seitenüberlauf durch zu lange Felder) usw., teilweise wurden bidirektional Daten aus Word vom Seriendruckvorgang auch direkt wieder zurückgespielt in die "Quelldaten". Lief immer problemlos, als es mal lief. Ich meine wir hatten anfangs auch noch eine interne Restart Funktion darin, wegen Memory Leaks. Restart musste dann aber im Echtbetrieb nicht eingesetzt werden, auch wenn den ganzen Tag gedruckt wurde. Es wurden im Extremfall mehrere Hochleistungslaserdrucker damit betrieben /beschickt.

Fazit: über COM Server bekommt man weitreichende Eingriffsmöglichkeiten, direkt vom Hersteller, ohne Umwege, ziemlich robust und konstant (für MS Verhältnisse).
Ist vermutlich heute immer noch so.

[blawen]

Zitat von jobo:

Fazit: über COM Server bekommt man weitreichende Eingriffsmöglichkeiten, direkt vom Hersteller, ohne Umwege, ziemlich robust und konstant (für MS Verhältnisse).
Ist vermutlich heute immer noch so.

Aktuell nutze ich diesen Weg auch für komplexere XLS und DOCX Files und habe bisher keine negativen Feedbacks erhalten.

[Lemmy]

Meine Erfahrung mit MS Office und COM Automation ist schon ein paar Jahre her, (Delphi 5 / Delphi 7 Tage) da war das noch etwas frickelig und instabil, auch weil gerne mal Virenscanner eine "Blutgrätsche" gemacht haben. Die OLE Automation mit OpenOffice war dagegen recht stabil.
Aktuell nutze ich die OExport Lib von Kluug.net um insbesondere XLSX zu lesen / füllen / schreiben, weil doch der eine oder andere kein Excel auf dem Rechner hat, das Format aber gefordert ist.

[dummzeuch]

Zum Erstellen von Excel-Dateien verwenden wir eine Bibliothek namens "Native Excel". Das hat für unsere Anwendung immer gut funktioniert.

Allerdings haben wir die schon vor ein paar Jahren gekauft (mit Sourcecode, versteht sich) und seitdem selbst geupdated, wenn notwendig. Als ich das letzte Mal danach gegoogled habe, schien es sie nicht mehr zu geben, aber gerade fand ich https://gmwteam.com/native-excel-3-1...o-full-source/ weiß aber nicht, ob es sich dabei um dieselbe Bibliothek handelt.