Inoffizielles deutsches Xbase-Forum

Hallöle.

Seit Jahren schlagen wir uns damit herum, dass L&L trotz selbstverständlich sehr ordentlicher und sorgfältiger Programmierung (die Nutzung erfolgt per DLL-Call) beim Beenden unserer Lösungen einen Runtime-Error (207, 206) generiert und manchmal dafür sorgt, dass sich DLLs unserer Anwendung nicht sauber entladen. Kürzlich habe ich aber irgendwo den Tipp gelesen, man solle "CMLLnnOC.LLX" aus der Auslieferung entfernen, also beispielsweise "CMLL26OC.LLX", wenn man L&L 26 einsetzt. Und, siehe da: Es wirkt. Eine sehr lange Testreihe mit zwei Parallelinstallationen brachte diejenige ohne diese Datei dazu, sich jedes Mal ordentlich zu beenden, während die andere once in a while einen Runtime Error erzeugte und sich zuweilen auch nicht sauber aus dem Speicher entfernte. Die Testreihe verwendete Druck (mit/ohne Vorschau), PDF-Export, HTML-Export, Excel-Export und RTF-Export, jeweils mit sehr komplexen Formularen. Aber die Docs sagen, dass LLX-Dateien in L&L für die Exportmodule zuständig wären. Der L&L-Debugger merkt nur an, dass die Datei nicht geladen werden kann, erzeugt aber keinen Fehler. Dafür ist, wie erwähnt, das Fehlverhalten offenbar verschwunden. Dennoch macht mich das stutzig. Weiß jemand, was diese Anwendungskomponente genau macht? Und/oder hat jemand das Problem des Sich-nicht-ordentlich-Entladens von L&L anders lösen können? Das Setzen der Reg-Value "SuppressGPFInfo", die irgendwo in den L&L-Docs mal empfohlen wurde, bringt jedenfalls nichts.

Ergänzung: Aus den Docs geht hervor, dass sie zu den vier (bzw. fünf) LLX-Dateien gehört, die als Exportmodule geladen werden, aber um welches es sich genau handelt, steht da nicht. Und alle Exporte scheinen zu funktionieren. Eigenartig.

cmLL26oc.llx (optional, OLE-Objekt)

wahrscheinlich um LLView in eine ANwendung einzubinden

PS: ich liefere die nicht aus, weil ich dachte, die bruach ich nicht. Ich installiere nur die LLX die ich aus dem Programm heraus auch erlaube. Dachte, dann lädt die DLL scheneller

hi,

bei mir steht : (optional, OLE-Objekt)

wenn du keine OLE "Einbindung" machst braucht man die nicht im Redistribution Pack

In der (Online-)Doku von List&Label steht, dass die CMLL26<cc>.LLX-Dateien (es sind insgesamt fünf, bei der Standardedition nur vier) zu den Exportmodulen gehören (im angezeigten Dokument per Browser-Suchfunktion nach "CMLL26" suchen):

https://docu.combit.net/progref/de/#!Do ... tring1.htm

Wie hier auch erwähnt wurde: In der REDIST.TXT steht dann wieder, dass es um das OLE-Objekt ginge. Das wäre die Fähigkeit, nach dem von Microsoft erdachten "Object Linking and Embedding" Office-Dokumente und Officekomponenten so in Formulare einzubinden, dass Verbunddokumente entstehen, sich also Dokumentenkomponenten gegenseitig aktualisieren. Das muss ich gleich mal ausprobieren.

Man kann solche Komponenten übrigens auch dadurch am Laden hindern, dass man LLSetOptionStr(<nJobHandle>,LL_­OPTIONSTR_­LLXPATHLIST,<cPathList>) verwendet, falls man sie doch ausgeliefert hat, weil man einfach alles ausliefert, was in den "Redistributierbaren Dateien" enthalten ist. Ein Dateiname, der mit Zirkumflex ("^") angegeben wird, wird am Laden gehindert:
@Marcus: Was meinst Du mit "LLView in eine Anbindung einbinden"? Meinst Du damit "LLPreviewDisplay(Ex)"? Das funktioniert auch ohne diese Komponente und gehört nicht zu den Exportmodulen. In der REDIST.TXT steht auch, dass CMLL26v.OCX das Vorschau-Control wäre.

LLView in eine Anbindung einbinden"

Ich hab vor Jahren mal einen LL Report als .LL in einen Dialog eingebunden. Ich hab nicht nachgesehen, wie ich das damals machte, ...hate mich nur daran erinnert

Tom hat geschrieben: ↑Do, 02. Sep 2021 11:55 Und/oder hat jemand das Problem des Sich-nicht-ordentlich-Entladens von L&L anders lösen können?

Ja. Beim Programmstart einen Dummy-Job anlegen der nie benutzt und erst beim Programmende beendet wird. Hat sehr geholfen.

siehe Doc:

Globaler "Dummy"-Job
Einige der von List & Label verwendeten Systembibliotheken (z.B. riched20.dll) schei-
nen unter bestimmten Umständen Ressourcenverluste zu verursachen. Diese sind
sehr klein, fallen aber bei jedem Laden und Entladen der DLL an.
Diese DLLs werden von List & Label bei jedem Öffnen bzw. Schließen des "ersten"
Jobs ge- bzw. entladen. Insofern sollten Sie in Ihrer Applikation ein häufiges LlJobO-
pen() / LlJobClose() vermeiden oder aber zu Beginn einen Dummy-Job öffnen und die-
sen bis zum Ende geöffnet halten. Damit wird das ständige Laden und Entladen der
DLLs umgangen, und neben einer dadurch erreichten Geschwindigkeitsoptimierung
werden auch die Ressourcenverluste nicht mehr auftreten

Hallo, Carlo.

Ich öffne ohnehin (je Hauptthread) nur einen Job und schließe den/die jeweils erst beim Appquit/Threadende. Und, nein, die sind alle ordentlich zu, das ist nicht die Ursache. Es lässt sich auch mit einem einzigen, einfachen Job nachstellen.