Beiträge von vsiebert

Danke für die rasche Antwort. Ggf. ist eine externe 64-Bit-Anwendung, die nicht den Speicher der Hauptanwendung "vollmüllt", vielleicht sowieso die bessere Variante.

Zur Frage 2: Klar, in WPDF_ViewCommands.pas stehen die ganzen Kommandos drin. In der Hilfe stehen die ja auch. Da steht aber (oft) nicht dabei, was man für welches Kommando in welchem Parameter übergeben muss.

Ganz explizit meine ich COMPDF_LoadEStream oder auch COMPDF_SaveToEStream. Kann man die über wpview_pdfWorkbenchCommand aufrufen?

Zunächst vorab: großes Lob für die Möglichkeiten in WPViewPDF4 Plus, PDF-Dateien zusammenzuführen und die dabei vorhandenen Möglichkeiten der Manipulation (Bookmarks, Hinzufügens von Text über Stamps, usw.) - da geht schon ziemlich viel.

Ich versuche gerade, relativ große PDF-Dateien zusammenzufassen, und habe dabei sowohl die Funktion wpview_pdfMergeW ausprobiert als auch eine Kombination aus wpview_pdfWorkbenchCreate/wpview_pdfWorkbenchLoad*/wpview_pdfWorkbenchCommand(COMPDF_SaveToFile).

Als Test wurden 5 Dateien mit insg. 366 MB Größe zusammengeführt. Die zusammengeführte Datei hatte danach eine Größe von 383 bzw. 386 MB und 2922 Seiten.

In einer Testanwendung benötigt wpview_pdfMergeW ca. 1,4 GB Hauptspeicher, die Kombination mit den Workbench-Befehlen ca. 1,0 GB. Beides klappt.

Das wäre aber ein ideales Szenario, das in einer echten Anwendung leider nicht vorkommt. Sobald vorher Speicher belegt wird, was in einem "natürlichen" Ablauf eher der Fall ist, klappt das Zusammenführen nicht mehr und bricht mit EOutOfMemory ab.

Bevor ich eine separate 64-Bit-Kommandozeilenanwendung für das Zusammenführen baue, hätte ich gerne gewusst:

1. Gibt es irgendwelche Parameter, mit denen man den Speicherverbrauch beeinflussen kann?

2. Gibt es irgendwo eine Liste, welche der COMPDF_...-Befehle von wpview_pdfWorkbenchCommand unterstützt werden und was man in welchen Parametern übergeben muss?

3. Aus Neugier: Wieso brauchen die beiden Verfahren unterschiedlich viel Speicher und wieso ist das Ergebnis leicht unterschiedlich?

Gibt es dafür einen Zeitplan? Sonst müssen wir uns eine Alternative einfallen lassen...

Hallo. Sind Sie schon dazu gekommen, es auszuprobieren?

Wenn Sie "wpmHide" meinen: das versteckt den Inhalt aber nicht die Bänder selbst.

Ein Kunde von uns hat sehr komplexe Berichtsvorlagen erstellt, in denen viele verschachtelte Report-Bänder verwendet werden. Dabei gibt es ein kleines Team, das die Vorlagen erstellt, während alle anderen Anwender die Vorlagen einfach nur verwenden und weiteren Text eintragen müssen. Die Bänder dienen dazu, den Ausdruck ganzer Blöcke zu steuern.

Dazu wird der Ausdruck der Bänder über Formeln im CheckCode geregelt. Die Parametern stammen entweder aus der Datenbank oder werden per Dialog abgefragt.

Das klappt auch schon ganz gut und wir klappen nach der Initialisierung die Bänder per Code so auf und zu, wie sie gedruckt würden, damit der Anwender sieht, welche Abschnitte relevant sind.

Da die Vorlagen recht komplex sind, sieht der Endanwender dann allerdings ganz viele leere aufeinanderfolgende farbige Balken mit den zugeklappten Bändern. Somit erfasst er selbst ansatzweise nicht mehr, wie der Ausdruck aussähe.

Kann man die Bänder ausblenden, ähnlich wie man z.B. die Darstellung von Absatzmarken und Gitternetzlinien umschalten kann?

Ein einfaches Löschen der Bänder kommt nicht in Frage, da der Anwender sich auch geirrt haben kann und daraufhin den Parameter-Abfragedialog neu startet. Der bereits eingegebene Text darf dabei nicht verloren gehen.