Inoffizielles deutsches Xbase-Forum

Hallo,
folgendes Zenario:
Ich erzeuge per Export nach PDF Abbilder einer LBL-Datei.
Bei ca. 70 Seiten/Dateien steigt der Speicherbedarf pro Datei um ca. 2500 kb, so dass am Ende ca. 180000 kb Speicher nicht freigegben sind.
Die Folge ist, dass danach ein Erzeugen eines Com-Objects nicht mehr möglich ist (Dokumentenviewer).
Nur Neustart des Programms hilft.
Gibt es irgendeine Möglichkeit/Funktionen in L&L, Speicher freizugeben ?
Die Ausgaberoutine ist hier mal extrahiert (vereinfacht):

Code: Alles auswählen

LL26ModuleInit()
hJob := LlJobOpen(-1)
   LlDefineVariableStart(hJob)

   ** Globale Einstellungen
	LlSetOptionString(hJob, LL_OPTIONSTR_LICENSINGINFO,   LL_LIZENZKEY)
	LlSetOption(hJob,       LL_OPTION_ESC_CLOSES_PREVIEW, .T.)
	LlSetOption(hJob,       LL_OPTION_SCALABLEFONTSONLY,  0)
	LlSetOption(hJob,       LL_OPTION_COMPRESSSTORAGE,    .F.)

   *************
   DefineDataTou(hJob)
   *************
   nRet := LlPrintStart(hJob, LL_PROJECT_LABEL, cLangName, LL_PRINT_EXPORT)

   ** Projektspezifische Einstellungen
	LlPrintSetOptionString(hJob,  LL_PRNOPTSTR_EXPORT, "PDF")
	LlPreviewSetTempPath(hJob, M->oFVW:FvwLocalTmpPath)
	LlXSetParameter(hJob, LL_LLX_EXTENSIONTYPE_EXPORT, "PDF", "Export.Path",       ConvToAnsiCP(Trim(M->oFVW:FvwLocalTmpPath)))
	LlXSetParameter(hJob, LL_LLX_EXTENSIONTYPE_EXPORT, "PDF", "Export.File",       ConvToAnsiCP(cExpDatei))
	LlXSetParameter(hJob, LL_LLX_EXTENSIONTYPE_EXPORT, "PDF", "Export.Quiet",      "1")
	LlXSetParameter(hJob, LL_LLX_EXTENSIONTYPE_EXPORT, "PDF", "Export.ShowResult", "0")

	nRet := LlPrint(hJob)
	do while nRet == LL_WRN_REPEAT_DATA
      nRet := LlPrint(hJob)
   enddo
   nRet := LlPrintEnd(hJob, 0)
   LlJobClose(hJob)
   LL26ModuleExit()

interessante Beobachtung. Muss ich nächste Woche gleich mal bei prüfen

Hallo Markus,
habe mal versucht, das ganze mit DsListLabel27 zu realisieren, um zu sehen, ob es vielleicht an meiner Ausgaberoutine für L&L liegt.
Dabei entsteht jedoch folgendes Problem:
Ich sehe meine Vorlage im Designer ohne Fehler, bei der Ausführung ohne Designer bekomme ich die Fehlermeldung -23 (Einer der verwendeten Ausdrücke hat einen Fehler...).
Daraufhin im Debugger nachgesehen, dort bekomme ich einen Fehler angezeigt: CMLL27 RTF control not loaded/loadable.
Habe auch schon die Option LL_OPTION_MAXRTFVERSION auf 0 gesetzt, schafft keine Abhilfe.
Es wird bei diesem Label-Projekt kein RTF benutzt.
Was kann ich tun ?

Im aufruf von dslistlabel():new(, lrtf) auf true setzen,dann wird rtf geladen. In der demo ist das ausgeschaltet

Am ende liegts am rtf. War schon immer was extra

Hallo Markus,
habe es jetzt hinbekommen - mit einigen Hürden - das ganze über dsListLabel auszugeben.
Leider mit dem Ergebnis, dass der Speicherverbrauch ebenso nach Erzeugung von 71 PDFs angestiegen ist.
Start mit Mem. Consumption 112176, Ende mit 190812, d.h. pro PDF ca. 2687 kb.

Echter Showstopper, leider auch schon mit der produktiv eingesetzten L&L Version 26 Sp3.

Die aktuelle Version funktioniert bei mir auch mit mehreren 100 Seiten PDF einwandfrei.
Der einzige Unterschied den ich auf die schnelle sah ist der dass es bei mir LST Projekte sind und ich den PDF Typ pdf3a verwende.

Code: Alles auswählen

LlXSetParameter(hJob, LL_LLX_EXTENSIONTYPE_EXPORT, "PDF", "PDF.Conformance","pdfa3a")

Hast du JPG's oder PDF in deinem Projekt? Mit solchen Zutaten die gewisse Kriterien erfüllten gab es schon die grössten Probleme!

Hallo Carlo,
ja, pro PDF können 1-3 png-Dateien (jeweils ca. 4 Kb) enthalten sein.

Jetzt muss ich doch glatt auch mal einen Test laufen lassen. Wir verwenden das intensiv, weil u.a. beim Rechnungslauf nur PDFs erzeugt und dann individuell verteilt werden (Post, Mail, Portalupload usw.). Und wir erleben hier und da und dort, dass der Speicherbedarf ansteigt.

Werde nochmal einen Test machen ohne die Png-Dateien einzubinden.

Mit oder ohne png-Dateien, dasselbe Verhalten.
Problem ist dann dabei, dass danach z.B. Rechnungen auf Drucker ohne Grafiken oder gänzlich weiß ausgegeben werden oder eben ActiveX-Komponenten zur Bildbetrachtung nicht mehr geladen werden können.

Habe jetzt mal einen Support-Case bei Combit eröffnet, mal sehen, was die dazu sagen.

mal sehen, was die dazu sagen

"Bitte senden Sie uns die gesamten Systeminformationen und außerdem einen Snapshot Ihres Gesamtsystems und einen umfassenden Speicherdump sowie ein ausführbares Beispiel, das das Verhalten demonstriert."

Wolfgang Ciriack hat geschrieben: ↑Mo, 01. Nov 2021 15:27 Habe jetzt mal einen Support-Case bei Combit eröffnet, mal sehen, was die dazu sagen.

Hallo Wolfgang,
wende dich mal zusätzlich an unseren Support.
Wenn ich meine Kollegen nicht völlig falsch verstanden habe, dann gibt es auch von uns einen Lösungsansatz.
Grüße, Frank

Danke Frank, habe ich gemacht.

Interessant ist, dass mit dem "alten" LegacyMode" (bis L&L 25) nur 39000 kB statt 195000 kB Speicher verbraucht wurde. Dafür ist die Verarbeitungszeit mit 57,5 s gegenüber 37,9 s doch etwas langsamer.

Heißt das im Umkehrschluß, es liegt an dsListLabel? Muss ich da suchen?

Nein, Markus, ob meine L&L-Klasse oder dsListLabel ist egal, es liegt an der Umstellung von L&L ab Version 26 auf eine neuere PDF-Rendering Engine.
Ich habe per Registry Key auf die "alte" PDF-Engine umgeschaltet, damit wird wesentlich weniger Speicher verbraucht.

Nachdem ich Combit ein Testprogramm zur Verfügung gestellt habe, haben diese das nachvollziehen können und eskalieren lassen. Jetzt ist das Problem zum Hersteller der PDF-Komponente gemeldet und auch da bestätigt worden. Man arbeitet dort wohl schon an einer Lösung. Fortsetzung folgt....

Hallo Frank,
vielen Dank nochmal für den Hinweis, mich an euren Support zu wenden.
Durch euren Lösungsansatz läuft mein Programm jetzt erst einmal trotz des hohen Speicherverbrauchs beim Erzeugen der PDFs ohne Folgefehler bei der Erzeugung von Rechnungsausgaben.

Und ist dieser Lösungsansatz so geheim, dass er hier nicht erläutert werden darf?

Hallo Tom,
ich wurde gebeten, diese Lösung nicht im Forum zu posten, da Sie diese dokumentieren und "im Auge" behalten wollen.
Aber es kann sich jeder gerne, wenn er solche Probleme hat, an den Support wenden.

So, habe jetzt die Info, dass das Speicherproblem mit dem ServicePack1 für Version 27 gefixt wird.
Eine vorab erhaltene DLL habe ich getestet, und es ist beim Speicherverbrauch wieder so wie mit L&L 25 oder dem "alten" LagacyMode, ein wenig, aber nicht mehr fortlaufend bis zur Fehlermeldung -102.

Mit dem Anfang der Woche veröffentlichtem L&L 26 ServicePack 5 ist der Speicherverbrauch korrigiert worden.

Inoffizielles deutsches Xbase-Forum

Speicherverbrauch bei PDF Erzeugung [Erledigt]

Speicherverbrauch bei PDF Erzeugung [Erledigt]

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung

Re: Speicherverbrauch bei PDF Erzeugung