RTF-Control meldet Problem nach der Installation des Service-Packs 3

Hallo,

wir haben das Service-Pack 3 von LL27 installiert und erhalten seitdem ein unerwartetes Verhalten beim Druck von Formularen mit RTF-Element “Formatierter Text” und fixem Text (keine Variablen im RTF-Element).
Das Problem tritt auf, wenn zwei unterschiedliche Formulare mit RTF-Element unmittelbar nacheinander gedruckt werden:

  • das erste Formular wird problemlos gedruckt
  • der erste Versuch das zweite Formular zu drucken verursacht einen internen Fehler mit dem RTF-Contriol, aber
  • jeder weitere Versuch druckt das zweite Formular problemlos.

Das Problem tritt nicht auf, wenn vorher das zweite Formular im Designer geöffnet (nicht gespeichert!) wurde - dort wird erwartungsgemäß natürlich auch kein Fehler angezeigt, da die Formulardefinition zu den Daten passen.
Das Problem tritt nicht in der Beispiel-Anwendung “PRTLOOP” auf, wenn ich ein RTF-Element in die Formulare hinzufüge.
Das Problem tritt aber wieder auf, wenn wieder das erste Formular zum ersten Mal gedruckt werden soll.

Das riecht nach einer Komponente, die vor dem ersten Versuch einen falschen oder veralteten Wert beinhaltet. Also handelt es sich vermutlich um ein Problem in unserer Anwendung, das bisher (also in LL27 ohne SP) toleriert wurde …
… nur was könnten wir vergessen haben?

Log des Fehlers

CMLL27  : 11:35:32.105 0000ffb8/02 1 [L01 API]:   LlSetDebug(new=0080, old=0080)
CMLL27  : 11:35:42.557 0000ffb8/09 2 [L04 PRN]:   EXPORT:Start failed: -99
CMLL27  : 11:35:51.633 0000fe14/03 3 [L01 TMP]:   WRN: RTF window 'RichEdit50W' can not be created
CMLL27  : 11:35:51.633 0000fe14/03 4 [L04 GEN]:   RTF control not loaded/loadable
CMLL27  : 11:35:51.633 0000fe14/03 5 [L04 GEN]:   Error -23 during load
CMLL27  : 11:35:51.633 0000fe14/03 6 [L04 GEN]:   Project load aborted, error -23(Einer der verwendeten Ausdrücke hat einen Fehler. Beim Designstart werden die Fehler interaktiv angezeigt. In anderen Fällen benutzen Sie den Debug-Modus zur Bestimmung des Fehlers.) occurred
CMLL27  : 11:36:07.228 0000a8ec/04 7 [L01 TMP]:   WRN: This job (1) is being closed by a thread that is different from the thread that created it. This might cause trouble.

Ich hatte mal ein ähnliches Problem.

Versuchs mal mit einem Schutzjob.

Eine globale Variable:
private static ListLabel _guardReport = null;

Beim Start des Programms:
guardReport = new ListLabel()

Beim Schließen des Programms:
if (_guardReport != null)
_guardReport.Dispose();

Ich hoffe, das hilft.

LG,
Marco

Danke für die Info.
Ich habe wohl vergessen zu erwähnen, dass es sich um VC++ handelt.
Der Druckjob wird beim Start des Programms mit LLJobOpen geöffnet und bis zum Ende des Programms verwendet.

Hallo!
Würde es mal mit dem aktuellen Service Pack testen und dann bei Bedarf samt komplettem Log direkt an combit melden. Meistens wollen die das sowieso :wink:

Grüße
HP

Guten Morgen,

interessant dürfte sein herauszufinden, warum das RTF-Control nicht geladen werden kann. Also diese Stelle hier:

List & Label verwendet zur Darstellung von RTF-Inhalten das RTF-Control von Microsoft resp. Windows (als Referenz dient hier WordPad). Je nach Betriebssystem-Version gibt es verschiedene RTF-Controls, z.B.:

RTF-Version: 3.1, RTF-Control: RichEdit20W, DLL: C:\WINDOWS\SYSTEM32\RICHED20.DLL
RTF-Version: 6.2, RTF-Control: RichEdit50W, DLL: C:\WINDOWS\SYSTEM32\MSFTEDIT.DLL

In List & Label lässt sich via LlSetOption(MaxRTFVersion, …) die RTF-Version beeinflussen. Könnten Sie bitte einmal schauen, welche RTF-Version die Anwendung verwendet? In der Log-Datei wird die RTF-Version relativ zu beginnen ausgelesen. Durchsuchen Sie das Log in Debwin nach “RTF”, dann sollte Sie schnell fündig werden. Wie verhält es sich, wenn eine andere RTF-Version verwendet wird?

Gerne können Sie uns auch die vollständige Log-Datei über einen Supportcase für eine weitere Analyse zur Verfügung stellen.

Grüße

Hallo,

hier wäre wahrscheinlich der gewünschte Block aus dem Log.

▪;1000;11.08.2022 16:45:18.022;2;LL.API;298C;100:2=CMLL27♦101:1=0; [CMLL27.DLL 27.3.2022.11816 (22-04-25 16:54)F]
▪;1000;11.08.2022 16:45:18.082;2;LL.Generic;298C;100:2=CMLL27♦101:1=10; looking for RTF control, max version 0xff00
▪;1000;11.08.2022 16:45:18.085;2;LL.Generic;298C;100:2=CMLL27♦101:1=10;  control 'RichEdit50W' in module 'C:\WINDOWS\SYSTEM32\MSFTEDIT.DLL' has version 0x0a00
▪;1000;11.08.2022 16:45:18.085;2;LL.Generic;298C;100:2=CMLL27♦101:1=10;   accept this one!
▪;1000;11.08.2022 16:45:18.085;2;LL.Generic;298C;100:2=CMLL27♦101:1=10; result: LL uses control 'RichEdit50W' in module 'C:\WINDOWS\SYSTEM32\MSFTEDIT.DLL' (supports RTF version 10.0)

Es scheint in der Tat einen Unterschied in den Versionen zu geben, allerdings ist mir unklar, wieso dieses Problem nicht immer auftritt sondern nur nach einem Wechsel des Formulars?

Viele Grüße und danke für die Unterstützung

Die verwendete MaxRTFVersion ist 0xff00 (-> dec: 65280) und die Voreinstellung von LL. Übersetzt bedeutet diese MaxRTFVersion 65280 so viel wie “nimm die neueste verfügbare RTF-Version”. In diesem Fall ist es RTF-Version 10.

Die verwendete RTF-Version ist tatsächlich nicht von dem Report/Formular abhängig, sondern eben von dieser Property MaxRTFVersion, die Code-seitig beeinflusst werden kann. Ändert sich das Verhalten, wenn eine andere RTF-Version verwendet wird? Können mit z.B. RTF-Version 6.2 (MaxRTFVersion = 1538) beide Formulare direkt hintereinander gedruckt werden?

© combit GmbH