wir versuchen gerade herauszubekommen, wie wir es hinbekommen eine exportierte LL Vorschaudatei nachträglich zu manipulieren auf einem System, wo kein List&Label mehr installiert ist. Es geht darum, dass die Vorlage nur aus einem eingebetteten PDF Dokument besteht, welches wir dynamisch austauschen müssen.
Soweit war schon rauszufinden, dass die ll Datei selbst wohl eine Compound Datei ist und in ihr innerhalb der Jobx/Pages/Indexx/ die einzelnen Page Dateien als EMF liegen.
Zur Vorgehensfrage:
Wäre beispielsweise in Job1/Pages/Index0 das gewünschte PDF zum EMF umzuwandeln und dort als “Page1” abzulegen?
Und danach die ganze struktur wieder als compound zusammenfassen und den Dateityp in *.ll umbenennen?
Es wäre super, wenn ein LL Entwickler uns ein paar Insights oder Tipps hierzu geben könnte.
Das was du dir wünschst ist natürlich theoretisch möglich. Wir können das ja auch . Allerdings würdest du damit das Rad neu erfinden. Warum nicht einfach das nutzen was es schon gibt?
Die Herausforderungen sind mannigfaltig: du müsstest die Storagedatei schreiben, ein PDF in ein EMF umwandeln und das hinterher alles wieder richtig zusammensetzen. Mit einer kleinen Druckschleife ist das in wenigen Minuten erledigt.
Wenn es definitiv sein soll dann melde dich nochmal, es gibt diverse APIs die zumindest ein bisschen helfen könnten. Die Umwandlung des PDF in das EMF Format müsste aber von dir selbst durchgeführt werden.
Das PDF in ein EMF umwandeln hatten wir testweise schon. Zugegebenermaßen mit einer externen Lib, aber es funktioniert bei unseren ersten Tests.
Aber wenn du mir ein paar Informationen geben könntest, wie die Storage Datei aussehen soll, was es hier ggf. für unterstützende APIs gibt oder auch alleine schon innerhalb der Storagedateistruktur, wohin genau das oder die EMF’s gehören, würde mich das schon sehr viel weiter bringen.
Hintergrundinfos: In der LLVorlage (Din A4) ist einzig ein Object (in der Basis Ebene ohne weitere Darstellungsbedingungen), nämlich ein PDF Object über die gesamte Fläche der A4 Seite. Ziel ist es nun programmatisch den Inhalt des PDFs aus einer fertigen LL Vorschau Datei (*.ll) auszutauschen (der Kunde speichert die LLVorschau Datei als byte[] in einer DB, wir haben nur Zugriff auf die DB könnten aber natürlich für den dynamischen Vorgang (PDF muss zur Laufzeit änderbar sein, bei einzigem Zugriff auf die DB) diese temporär lokal abspeichern, entsprechend manipulieren und wieder in die DB schreiben.
Vielen Dank schon einmal und ebenfalls ein schönes WE;
Marc
Dürfen es zumindest LL-APIs aus der Vorschau-DLL sein? Oder muß es völlig ohne LL laufen? Das interne Format der Vorschaudateien ist nicht dokumentiert und kann sich jederzeit ändern. Es gibt aber einige APIs innerhalb LL für die Manipulation.
Zusätzlich gibt es (undokumentierte) Funktionen um Metafiles als neue Seite hinzuzufügen. Da kann ich dir am Montag mal was zusammenstellen.
Überleg dir aber nochmal, ob du das nicht einfach direkt mit LL machen willst - das wäre in jeder Hinsicht einfacher, es braucht keine andere Bibliothek. Dass LL lizenzgebührenfrei an Endkunden weitergegeben werden kann ist dir bekannt? Die einzige wichtige Voraussetzung ist die Einbindung in eine Gesamtanwendung.
“Dass LL lizenzgebührenfrei an Endkunden weitergegeben werden kann ist dir bekannt? Die einzige wichtige Voraussetzung ist die Einbindung in eine Gesamtanwendung.”
In der Gesamtanwendung ist es in der Tat schon vorhanden. Einzig kann der Kunde nicht sicherstellen, dass diese Anwendung auf allen PCs im Unternehmen installiert ist, auf denen eine Manipulation der VorschauDatei erfolgen soll. Aber wenn das lizenztechnisch ausreicht um die nötigen LL Libs mitauszuliefern wäre das natürlich der denkbar einfachere und versionssichere Weg.
Sähen die LL API Requests wie folgt aus?:
LlStgsysStorageOpen (Storage öffnen)
LlStgsysDeleteFiles (bisherige Seite(n) löschen)
LlStgsysAppend (neue PDF Seiten anhängen/einfügen)
LlStgsysStorageClose (Storage schließen)
Frage: Wird beim Storage schließen auch dessen Veränderungen autom. gespeichert oder ist das ein weiterer Befehl den ich übersehen habe ?
Am einfachsten wäre es dann, wenn die Anwendung auf allen Systemen installiert wäre. Dann würde ich einfach eine Projektdatei mit einem PDF vorstehen und die dann jeweils aktualisiert drucken. Dann bräuchte es auch die Storage-APIs gar nicht.
Ansonsten müsstest Du eine neue Storage erzeugen und da die Seiten reinhängen, die APIs sind aber nicht dokumentert und verwenden z.T. interne Strukturen:
LlStgsysStorageCreate
LlStgsysAppendEMFEx
Die Deklarationen dafür:
Diese API liefert Dir ein Handle auf eine leere, neue Storage:
Allerdings sehe ich gerade, dass der PILlPreviewDeviceInfo Pointer gefüllt sein muß, das wird “von außen” sehr schwierig. Da müssten wir vielleicht eine Möglichkeit anbieten, hier auch NULL zu übergeben und dann ein Default-Deviceinfo zu nutzen.
Langer Rede kurzer Sinn - ich würde das unbedingt so wie oben beschrieben lösen und im Kontext der Anwendung die Möglichkeit anbieten, einen Druck mit aktualisiertem PDF auszulösen. Dann ist es sauber, dokumentiert und zukunftssicher .
Das kann der Kunde wie gesagt nicht sicherstellen. Auf manchen Systemen wird es so sein, auf anderen nicht. Nichtsdestotrotz muss jeder Außen PC (der nur auf eine DB zugreifen kann, was die LL Vorschau Datei gezippt als Byte abgelegt ist] die Möglichkeit haben das PDF in der LL Vorschau Datei selbstständig zu verändern, sodass danach einer der internen Server (Wo die Gesamtanwendung mit LL auch installiert ist und läuft) diese intern ausdrucken / lokal auf dem Srv abspeichern (als PDF) kann.
Auf die Gesamtanwendung haben wir keinen Einfluss, diese ist von einem externen Entwickler.
Ist es möglich, in der von uns erstellen Anwendung auf den externen Rechnern (ohne LL Installation, ohne Gesamtanwendung mit LL Installation) denn dennoch benötige LL Assemblies mit auszuliefern, referenzieren um darüber eine neue LL Vorschaudatei mit neuem PDF zu erzeugen und in der DB abzuspeichern ?
Oder geht dies technisch nicht, bzw. verstößt gegen eure Lizenzbestimmungen?
Falls es nicht gehen sollte aus einem der beiden Gründe, bliebe uns in der Tat nur der Weg das EMF zu erzeugen und in einem neuen Storage abzulegen. Um das Erzeugen des EMF haben wir uns schon gekümmert, bzw. einen Weg evaluiert. Aber für das erzeugen des Storages Files und der nötigen Struktur in diesen wäre ein Tipp von dir Gold wert
Wenn ihr selber nicht die Hersteller der Anwendung seid geht das so in der Tat nicht - die Weitergabe und Referenzierung der Dateien ist nur möglich, wenn ihr entsprechend lizenziert seid. Ihr könntet natürlich einfach eine Lizenz kaufen . Oder der Hersteller der Anwendung strickt das benötigte Feature dran.
Direkt selber die Storage zu schreiben kann ich euch nicht empfehlen, wir verändern das Format immer mal wieder und dann landet ihr auf dem Bauch…
Das dachte ich mir schon
Dann probieren wir erst noch einmal Rücksprache mit dem Hersteller des Gesamtsoftware zu halten, ggf. arbeitet er etwas für uns ein.
Danke dir auf jeden Fall aber dennoch schon einmal für deine ausgesprochen gute Hilfestellung hier im Forum!