Serie Druck eines office Document

[Muecke]

Hallo zusammen,

hat jemand Erfahrung mit Seriendruck eines Office Documents(doc,dot).
Drucker sollte auswählbar sein.
Kann mir da jemand helfen oder ein Typ geben.

Gruss Thomas

[Koverhage]

Hallo Thomas,

echte Word Dokumente mit Seriendruckfelder?

Da kann ich nicht helfen, aber bei unserer Software läuft es so:

Anwender legt die Seriendruckfelder als Textmarken fest.

Hier können natürlich nur die festgelegt werden, welche vom Programm dafür vorgesehen sind.

Der Anwender wählt den Drucker aus, welcher dann per PrinterApi (siehe www.idep.org.uk #26) als Standarddrucker gesetzt wird.
Nach dem Drucken der Serienbriefe wird die Einstellung zurückgesetzt.

Klaus

[Muecke]

Hallo Klaus,

bin ich richtig der Annahme, dass ich selber wählen kann wo ich Adressen
Text,Grussformal usw....will.
Das würde mich mal intressieren wie dies geht.
Wo und wie kann ich dies machen.
Geht das auch wenn ich im Word einen Text schreibe und dann meine Adressfelder und was noch dazugehört via Textmarken selber festlegen.
Das wäre spitze für mich.
Hast Du da ein Beispiel.Ich sammle meine Kunden in einem Array damit ich den Kundenstamm beisammen hab.
Würde dies so funktionieren mit dem Array?


Gruss Thomas

[brandelh]

Hallo,

Seriendruckbriefe unter Word, erstellt man (bei Word 2000, andere eventuell andere Bezeichnungen) folgendermaßen:

1. Extras / Seriendruck, jetzt erscheint ein Assistent.
2. Falls noch nicht vorhanden wird das Hauptdokument 1. erstellt.
3. Bevor man nun bearbeitet, muss man die Daten importieren (DBF oder anderes Format festlegen).
4. Felder einfügen (Hauptdokument bearbeiten)
5. Seriendruckfelder oder Bedingungsfelder einfügen wo sie hin sollen. Dazwischen normalen Text.
6. Die DBF vom eignenen Programm aus erzeugen, dass nur zu druckende Datensätze drin sind und man spart sich die Filterfelder.

Bei neueren Versionen kann man vorgefertigte Adressschablonen oder einzelne Felder einfügen, letztere sind für DBF Vorlagen besser.

Aber das ganze hat mit ActiveX erstmal nichts zu tun.
Zum Drucken könnte man mit RunShell() Word mit dem Hauptdokument als Parameter starten, dann soll der Anwender Serienbriefe drucken.
Falls diese Steuerung über ActiveX gehen soll, alles in einem Word Macro speichern und sich dieses später ansehen. Der Code ist in VBA, das sollte man lesen und übersetzen können.

Will man, dass XBase die Kontrolle über den Druck etc behält, muss man wie Klaus geschrieben hat Textfelder oder benannte Texte mit festgelegten Inhalten im Worddokument einbetten, die man mit AktiveX später sucht und ersetzt um das einzelne Dokument zu drucken:

Z.B. in Word {DBF_Anschrift_Name1} -> ersetzen mit alltrim(DB->Name1)

[Koverhage]

Hallo Thomas,

kann die den Source-Code per E-Mail zukommen lassen.
Wenn Interesse besteht (und ich wüßte wie ich das mache, am besten ich schicke den zu Hubert) könnte ich den auch hier ins Forum stellen.
(aber erst heute Abend)

Gruss
Klaus

[Koverhage]

Thomas,

jetzt noch deine restlichen Fragen.
Ja es funktioniert alles super, Arrays kein Problem,
Du kannst das Dokument so einrichten, das die Felder
dort sind, wo sie sollen.
Schicke Dir dann auch ein Word Dokument.

[Koverhage]

Hubert,

Deine Vorgehensweise ist zwar im Prinzip richtig, aber zu aufwendig
Bei unserer Anwendung läuft es z.B. so.
Aufruf des Briefes/Serienbriefs, füllen der Briefe mit den Werten,
dann verschieben in den Archivordner des Kunden und Ausdruck des Briefes.
Dies Selektion der Serienbrieferstellung z.B. alle Kunden mit Wartungsvertrag läuft im Xbase++ Programm.

Klaus

[brandelh]

Deine Vorgehensweise ist zwar im Prinzip richtig, aber zu aufwendig

Hallo Klaus,

ich hatte lediglich beschrieben, wie unter Word ein Serienbrief erstellt wird. Zu Clipperzeiten haben wir unsere damalige Windowstextverarbeitung (AmiPro) für Serienbriefe nach diesem Grundmuster benutzt, da Clipper nicht so toll drucken konnte.

Heute drucke ich in meinen Programmen ausschließlich mit meiner eigenen Druckerklasse. Deine Vorgehensweise ermöglicht es dem Anwender seine Briefe selbst abzuändern, was ein großer Vorteil sein kann. Was für Thomas am Besten ist, weiß ich nicht.

PS: wer eine ZIP Datei mit Quellcode zum Thema anbieten will, kann diese an mich senden. Je nach Wunsch kann ich dann in eine bestehende Message einen Link setzen oder die Linkadresse zumailen.

[Muecke]

Hallo Klaus

Das ist das was ich suche.
Im Word den Brief erfassen und dan mit ein Seriendruck an meine Leute senden.
So könnte ich auch den Drucker via xbase++ kontr.

Gruss Thomas

[Muecke]

Hallo Hubert,

ich danke dir für Erklärung. Mache dies jetzt via Word, bis ich eine Routine für Seriendruck im xbasse++ hab.

Gruss Thomas

[Tom]

Wir bieten dafür mehrere Alternativen. Es gibt ein einzubindendes Makro, das ein Word-Menü erzeugt, aus dem heraus direkt in Word viele Platzhalter zu wählen sind, die es aus unserem Programm heraus gibt. Aus unserer Applikation heraus wird dann Word via ActiveX gestartet, und per SearchReplace werden die Platzhalter ersetzt. Das Dokument kann im Anschluß gedruckt werden, auch aus der Applikation heraus, und auf Wunsch ohne daß Word sichtbar wird. Optional wird es unter einem automatisch generierten Dateinamen gespeichert. Nachteil: Word per ActiveX ist schrecklich langsam. Und es muß natürlich installiert sind. Aber technisch ist das kein großer Aufwand. Vorteil: Es stehen alle Word-Funktionalitäten zur Verfügung, und selbst innerhalb der Platzhalter durchgeführte Formatierungen lassen die Systematik nicht scheitern.

Die zweite Alternative sind RTF-Dokumente, die via TX TextControl innerhalb der Applikation geschrieben werden. Die parsen wir direkt nach den auch hier über ein Menü zu wählenden Platzhaltern. Das geht sehr viel schneller, und wir drucken dann über L&L oder über die Druckfunktionen von TX TextControl, das nahezu alle Standardfunktionalitäten bietet, bis hin zu Hyperlinks, Tabellen usw. Nachteil: Formatierungen innerhalb der Platzhalter (die aber genaugenommen keinen Sinn machen) lassen die Systematik scheitern. Großer Vorteil: Es ist völlig egal, welche Office-Software auf dem Rechner installiert ist. Alles geschieht innerhalb der Applikation.

Serienbriefe völlig außerhalb der Anwendung funktionieren nur bei nicht-normalisierten Datenbanken und bei relativ anspruchslosen Serienbriefen (nur Adressen). Sobald umfangreiche Relationen eine Rolle spielen, also jenseits der Adressen sehr viel mehr Daten möglich sein sollen, scheitern diese Ansätze.

[Martin Altmann]

Hallo Tom,

Serienbriefe völlig außerhalb der Anwendung funktionieren nur bei nicht-normalisierten Datenbanken und bei relativ anspruchslosen Serienbriefen (nur Adressen). Sobald umfangreiche Relationen eine Rolle spielen, also jenseits der Adressen sehr viel mehr Daten möglich sein sollen, scheitern diese Ansätze.

es sei denn, man stellt exra dafür eine konsolidierte, temporäre dbf bereit, die alle Informationen enthält und als Grundlage für die Serienbriefe benutzt werden kann.

Viele Grüße,
Martin

[Tom]

Hallo, Martin.

Diesen Ansatz kann man auch noch weiter treiben, zum Beispiel über die Importfunktionalitäten der Kontaktdatenbank von Outlook, die ja durchaus recht flexibel ist. Wenn man aber dem Anwender möglichst viele Zwischenschritte ersparen will, sind die Ansätze über ActiveX (Direkt) oder RTF (Komponente) meiner Erfahrung nach die praktikabelsten.

[Lewi]

Hallo miteinander,
ich möchte hier einen Lösungsansatz vorstellen, den ich mittels JazeAge entwickelt habe. Leider bin ich bisher noch nicht dazu gekommen, das ganze auf ActiveX in Verbindung mit 1.9 umstellen. Es dürfte aber kein Problem darstellen, den Code entsprechend umzustellen.


Schritt 1
Eine Beispiel-Datenquelle generieren (z.B. DBF)

Schritt 2
Mit Word eine Formatvorlage anlegen, die als Template den Serienbrief dienen soll. Die Beispieldatenbank dient dazu, die Felder in das Formular einzufügen.


Schritt 3
Für die Erstellung eines Serienbriefes sollte die abgespeicherte Formatvorlage in ein temporäres Verzeichnis gespeichert werden. Dies gilt ebenso für die Daten des Serienbriefes.

Schritt 4
Aufruf der Funktion Serienbrief( cFormatvorlage, cDatenFile, cPrinter )



Die Funktion Serienbrief()

Code: Alles auswählen

Func Serienbrief(cDoc, cDat,  cPrinter )

  Local oWord, oDoc,  
  Local cActivePrinter	:= ""
  Local savepath			:= "Temp$.doc"


  cPrinter := IIF( cPrinter <> NIL, StrTran(cPrinter, "~","")
  oWord:=JAObject():New()
  oWord:Connect(JAXPPCREATEACTIVEXOBJECT("ProgID:Word.Application"))
  <oWord:Visible:=.T.>
  If cPrinter <> NIL 
     cActivePrinter := <oWord:Activeprinter>
     <oWord:Activeprinter:= cPrinter>
  endif

  oDoc :=JAObject():New()
  oDoc:Connect(<oWord:Documents:Add("Template",cDoc)>)
  <oDoc:MailMerge:MainDocumentType:=wdFormLetters>
  <oDoc:MailMerge:OpenDataSource(cDat)>
  oDoc:Disconnect()
  if cPrinter <> NIL
     <oWord:Activeprinter:= cActivePrinter>
  endif
  oWord:Disconnect()
  Return ( NIL )

Innerhalb von Word steht nach dem Aufruf dieser Funktion innerhalb des Dokumetes die komplette Serienfunktionaltät zur Verfügung. So kann beispielweise zwischen den Ansichten gewechselt werden (Paltzhalter vs. Datenanzeige).

Das Setzen eines Druckers ist hier optional. Der Anwender könnte auch innerhalb von Word einen Drucker wählen.

Die Schritte 1 und 2 sind nur einmal für die Erstellung der Formatvorlage durchzuführen.

Gruß, Olaf

[Lewi]

Übrigens, die (selektierten) Daten für einen Serienbrief speichere ich in eine separate, temporäre DBF-Datenbank.

[brandelh]

Mache dies jetzt via Word, bis ich eine Routine für Seriendruck im xbasse++ hab.

Für externe Programme sollte man jeweils eine temporäre Datei aus der eigenen Anwendung generieren (ohne MEMO, Logisch -> 0/1 oder "J"/"N", Datum -> ctod() etc.), um Format- und Sharingproblemen aus dem Wege zu gehen. Außerdem kann dann nichts mit den original Daten geschehen.

Wenn Deine Druckausgaben bis auf die variablen Teile fix sind (Rechnungen etc.) kann ich meine Druckerklasse oder einen guten Reportgenerator empfehlen.

[Muecke]

Hallo Hubert,

Ein Reportgenerator, wie soll der heissen und wo finde ich der?

Wie kann ich im Word {DBF_Anschrift_Name1} -> ersetzen mit alltrim(DB->Name1).
Wie finde ich solche Befehlszeilen?
Ist für mich noch Neuland.Wo kann man dies nachlesen?

Gruss Thomas

[AUGE_OHR]

hi,

hat jemand Erfahrung mit Seriendruck eines Office Documents(doc,dot).
Drucker sollte auswählbar sein.

warum nimmst du nicht einfach das Alaska Sample :

C:\ALASKA\XPPW32\SOURCE\samples\activex\msword\feed.prg

das ist zwar für "Serien-Fax" aber das Prinzip wird ja wohl das gleiche sein ?

Also mache dir von der FAX.DOT eine Kopie MYSERIE.DOT. Nun öffnest
du "Word" und lädst MYSERIE.DOT. Nach dem bearbeiten wieder als
*.DOT Datei abspeichern und mit dem Alaska Sample die MYSERIE.DOT
laden und ausführen.

gruss by OHR
Jimmy

[Lewi]

Moin Jimmy,
das Fax-Beispiel nutzt die Serienbrief-Funktionaltät von Word in keinster Weise. Es ist ist ein gutes Bespiel für das "Suchen und Ersetzen von Bookmarks".

Viele Grüße
Olaf

[Muecke]

Hallo Jimmy,

hab dies auch so in Funktion.
Was ich aber noch brauche, wie steuere ich den Dialog für die Printerklasse an,damit ich einen Drucker wählen kann.

Gruss Thomas

[Manfred]

Hi Thomas,

meinst Du sowas hier?

Code: Alles auswählen

oDlg := XbpPrintDialog():new():create()
oPrinter := XbpPrinter():new():create()
oprinter := oDlg:display()

Jetzt müßte das Fenster für die Auswahl aufgehen

[brandelh]

Hi,

das nützt ihm aber nichts, da er ja nicht mit Xbase++ drucken will, sondern mit Word.
Weiter oben hat jemand die Quelle einer Datei von Phil beschrieben, mit der der Standarddrucker festgelegt werden kann.

Mit

oP := oXbpPrinter():New() // nicht createn !!!
oP:list()

erhält man die Liste der installierten Drucker.
Jede Zeile enthält einen gültigen Druckernamen, die würde ich in einer Listbox zur Auswahl anzeigen, alle anderen Einstellungen sind sowieso nicht zu gebrauchen (da ja mit Word gedruckt wird).
Dann den gewählten mit Phils Programm als Standard setzen und drucken.

Die Frage nach einem guten ReportGenerator würde TOM mit List&Label beantworten, ich kenn mich damit nicht aus und kann dazu nichts sagen.

[Manfred]

jaja, das hatte ich mir gedacht. In der Hektik wollte ich auch mal helfen und dann sowas......

[andreas]

Versuche zum Drucken folgendes zu nehmen:

Code: Alles auswählen

oWord:ActiveDocument:PrintOut()

[Tom]

Hallo, Muecke.

Code: Alles auswählen

Ein Reportgenerator, wie soll der heissen und wo finde ich der? 

Reportgeneratoren sind Zusatztools/-programme/-bibliotheken, die i.d.R. aus zwei Komponenten bestehen, nämlich einem Formulargenerator/-designer und einer Runtime-Komponente, die für den Ausdruck der Formulare sorgt. Dabei gibt es zwei grundsätzlich unterschiedliche Ansätze. Reportgeneratoren wie der R&R Report Writer "kennen" verschiedene Datenbankformate und greifen direkt auf diese zu. Bei der Erzeugung von Formularen gibt man, quasi unabhängig von der Applikation, Relationen an, setzt Filter usw. Das Formular enthält also nicht nur Informationen zur Gestaltung des Ausdrucks, sondern auch die Datenerhebung selbst. Der Vorteil besteht darin, daß man bis auf den Aufruf der Runtime-Komponente im Programm nichts tun muß, aber es ist für die Anwender deutlich schwerer, Formulare zu generieren. Der Zugriff auf Programmfunktionen und UDFs steht nicht zur Verfügung. Der Programmierer hat keine Kontrolle darüber, welche Daten wie ausgewertet werden. Sehr vereinfacht gesagt.

Der von mir bevorzugte und immer wieder gerne angepriesene Formulargenerator Combit List & Label (http://www.combit.net) geht einen anderen Weg. Die Applikation muß - über DLL-Funktionsaufrufe - alle Variablen und Felder explizit publizieren. Jedes Formular bekommt auch nur die Daten, die es berücksichtigen soll. Das hat zwei Vorteile: Der Anwender pfuscht nicht in den Daten herum. Und man kann alle Arten von Daten publizieren, also auch Memvars. Im Formular ist nicht mehr sichtbar, wo die Daten herkommen, ob sie also direkt aus Tabellen stammen oder zur Laufzeit erzeugt worden sind. Allerdings muß man Datenübergabeprozeduren schreiben, jeweils abhängig von den auszuwertenden Daten, was aber auch allgemeingültig - etwa für den einfachen, direkten Ausdruck einer Tabelle - in generischen Routinen machbar ist.

Formulargeneratoren können inzwischen weit mehr als nur einfach ausdrucken. Sie erlauben neben einfachen Dingen wie Druckvorschau, Datenexport in zig Formate, Mail- und Fax-Direktversand auch Dinge wie die Einbindung von RTF, DOC, HTML (auch aus Online-Erhebung), sogar COM-Komponenten. L&L beherrscht verschachtelte Kreuztabellen. Barcodes entstehen durch einfachen Funktionsaufruf im Formular (Barcode$(cMeinFeld,"EAN128") oder ähnlich). Charts und Statistiken innerhalb des Formulars sind ohne zusätzliche Vorarbeiten möglich. Die Gestaltungsmöglichkeiten sind vielfältig, von der automatischen Anpassung der Schriftgröße abhängig von der Länge des Textes über bedingungsabhängige Darstellungsebenen (das Formular verhält sich je nach Datenquelle ganz unterschiedlich) und vieles mehr. L&L kann per DLL-Call eingebunden werden, m.E. der eleganteste Weg, steht aber auch als ActiveX-Komponente und für .NET zur Verfügung. Der Laufzeitdesigner ist steuer- und konfigurierbar, man kann ihn kostenlos (je nach Version) an die Endkunden weitergeben. Und vieles, vieles mehr.

Wir haben es anfangs mit plain-Xbase-Direktdruck versucht, dann haben wir die DCPRINT-Engine des ohnehin eingesetzten Zusatztools eXpress++ genutzt. Aber zwischen diesen Ansätzen und dem Einsatz eines professionellen Reportgenerators liegen Welten. Unsere Anwender sind quasi gestaltungsfrei. Aber wir haben immer noch die volle Kontrolle darüber, welche Daten ausgedruckt werden bzw. zur Verfügung stehen. Und es gibt keinen direkten Zugriff auf die Tabellen.

Allerdings existiert ein Aber. Das Konzept von L&L ist nicht ganz unkompliziert, man muß es verstehen. Sobald das aber geschehen ist, wertet man die Applikation enorm auf. Und die Möglichkeiten sind so gut wie unbegrenzt.

(Ende des Exkurses.)