Office-Dokumente erzeugen: Automatisierung oder nicht?

[Der schöne Günther]

Ich muss zum ersten mal mit Office-Dateien hantieren, das ist eigentlich nicht meine Welt. Es geht um ein kleines In-House-Tool das fertige Word- & Excel-Dateien ausspucken soll.

Ich bin mir unsicher, welche technischen Möglichkeiten man nutzen soll: Delphi bringt ja beispielsweise irgendwelche Header für Office-Automatisierung über COM mit. Wenn ich es richtig verstanden habe setzt das verständlicherweise voraus, dass lokal Office installiert ist und vernünftig funktioniert.

Dann gibt allerdings auch Bibliotheken die überhaupt nicht von Office abhängig sind und die entsprechenden Dateien direkt lesen und schreiben können. Ich habe letztes Jahr einmal etwas mit NPOI (Github, Nuget) gemacht und war eigentlich begeistert wie easy und zuverlässig das funktioniert hat.

Bei der Office-Automatisierung mache ich mir Sorgen dass

• ich gefühlt öfter hier im Forum lese wie nach irgendeinem Office/Windows-Update wieder irgendwas klemmt
• Sich der Kram verhält wenn der Bediener schon ein Dutzend Word & Excel-Dokumente offen hat
• Ich eine Office-Installation brauche wenn ich den Kram z.B. lieber auf einen Server packe und das nur per Web-Oberfläche aufrufen lasse
• Ich keine Ahnung habe wie man das groß debuggen könnte, der Office-Kram ist ja dann für mich eine Blackbox in einem anderen Prozess

tl;dr: Ich sehe keinen wirklichen Grund weshalb man das über Office-Automatisierung lösen sollte. Kann jemand einen Vorteil nennen den ich vielleicht übersehen habe?

[hstreicher]

Word muss ich zum Glück nicht machen:)

für Excel verwende ich die TMS AdvStringgrid Komonenten die haben eine Excel Export Import
und habe seitdem gefühlt eine Zillon Probleme weniger

die meisten Probleme waren bei mir dass der User in das Word oder Excel Blatt geklickt hat und dann die
Verbindung zwischen Delphi und Office verloren ging

mfg Hannes

[Delphi.Narium]

Zitat:

Zitat von hstreicher (Beitrag 1490887)

die meisten Probleme waren bei mir dass der User in das Word oder Excel Blatt geklickt hat und dann die
Verbindung zwischen Delphi und Office verloren ging

Das ist dann aber eher ein Implementierungsfehler.

Man kann sich auch eine eigene Instanz von Word, Excel, ... aufmachen und die versteckt arbeiten lassen. Der User bekommt davon nix mit.

Wenn aber der User aus Delphi heraus (o. a.) den Aufruf der Automatisierung (für das aktuell von ihm bearbeitete Dokument) startet, so kann man das Officeprogramm für die Dauer der Automatisierung verstecken und erst wieder anzeigen, wenn der "Job" erledigt ist.

Weiterer Vorteil: Automatisierte Officeprogramme arbeiten versteckt deutlich schneller, da nicht mehr permanent die Anzeige aktuallisiert werden muss und versehentliche und kontraproduktive Klicks, sind nicht mehr möglich.

Weiterer Vorteil der Automatisierung:

Man kann Vorlagen nutzen und in denen Felder befüllen, zu Sprungmarken gehen und dort nur die entsprechenden Fragmente einfügen, die abschließende Optik, Seitenlayout, ... per Makro vom Officeprogramm aufbereiten lassen ...

Letztlich kommt es darauf an, was man eigentlich will:

0815 Dokument erstellen
Geschäftsbriefe mit individuellen Daten bestücken.
Einfach nur Daten als Report "ausspucken"
...

Je mehr officeprogrammtypische Aufgaben zu erledigen sind, um so mehr spricht für die Automatisierung.
Geht es nur um die pure Ausgabe von Daten und die sind ohne großen Aufwand auch ohne Officeprogramm im Officeformat auszugeben, denn spricht nichts für die Automatisierung.

Hat man für eine Problemlösung per Automatisierung aus Delphi heraus mal keine Ahnung, kann man die entsprechenden Schritte mal im Officeprogramm ausführen und als Marko aufzeichnen. Den Quelltext Copy&Pastet man sich in den Delphiquelltext und passt sich die Syntax entsprechend an. Am Anfang ist das etwas mühselig, aber mit Programmiererfahrung hat man den Dreh recht schnell raus und kann sich so recht einfach das erforderliche KnowHow aneignen.

Aber so eine Empfehlung der Art:

Code:

Automatisierung ist Grundsätzlich gut
Automatisierung ist Grundsätzlich schlecht / nicht empfehlenswert, abzulehnen ...

ist für meine Begriffe nicht seriös.

[Uwe Raabe]

Für den Fall, dass du dich für die Bibliotheksvariante entscheidest und diese native Delphi ist, wäre ich dann später an deinen Erfahrungen damit interessiert.

[Harry Stahl]

Sind die zu erstellenden Word- bzw. Excel Dokumente komplex oder eher von einfacher Art?

Ich gehe mal davon aus, dass docx und xlsx Dokumente erzeugt werden sollen?

Es ist gar nicht so schwer, diese Dokumente selber mit Delphi zu erstellen oder zu bearbeiten, hier gibt es ein sehr interessantes Video dazu: https://www.youtube.com/watch?v=28Yy9fJ78rA

Dann braucht man auch kein installiertes Office vor Ort.

Evtl. ist das ja für Dich von Interesse.

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

Zitat von jobo (Beitrag 1490914)

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.