Guten Tag,
folgendes Verhalten entsteht beim Öffnen des Designers mit Druckdaten, deren Format nicht zu verwendeten Funtionen passen.
z.B.
Mein Anliegen:
Kann das ausgewiesene Protokoll
vom Programm ausgelesen werden, damit das Format der Druckdaten angepaßt werden kann?
vielen Dank für Hinweise
Sie können das ExpressionError-Event bzw. den entsprechenden Callback dafür verwenden, die auftretenden Fehler zu sammeln. Allerdings ist es beim Öffnen des Designers schon zu spät, um noch Änderungen an der Datenstruktur vorzunehmen. Wenn Sie dies tatsächlich auf diese Weise lösen wollen müssten Sie das Projekt im ersten Schritt per DOM öffnen und die dabei auftretenden Fehler (die die gleichen sein sollten) sammeln. Dann könnten Sie im Designeraufruf den Datentypen anpassen.
Ein einfacher (und vielleicht eher zu empfehlender) Workaround wäre die Verwendung von ToString$(). Wenn Sie in der Formel einfach ToString$(variablencontainer.Zeichen) + " vom User gesetzt" verwenden sollte die Ausgabe immer korrekt sein, unabhängig davon welchen Datentyp die Variable hat.
vielen Dank Herr Preuschoff für den guten Hinweis.
Leider konnte ich in der Dokumentation zum ExpressionError nichts finden. Könnten Sie mir einen Hinweis geben wie es unter Delphi angesprochen/genutzt werden kann.
vielen Dank
In Delphi heißt der Event OnExprError. In der Onlinehilfe der VCL-Komponente finden Sie eine kurze Dokumentation:
Deklaration
property OnExprError: TNtfyErrorEvent;
Beschreibung
Das Ereignis wird ausgelöst, sobald es zu einem Ausdrucksfehler in einem Projekt kommt. Die übergebenen Fehlertexte können gesammelt und anschließend dem Benutzer angezeigt werden.
Das Event funktioniert und für den Hinweis bin ich Ihnen sehr dankbar.
Leider habe ich am Anfang meine Frage nicht ausreichend gestellt. Denn im Nachhinein erweißt sich der Fehlertext nicht immer ausreichend, siehe Bild:
Könnten Sie mir auch hierbei weiterhelfen?
vielen Dank für Ihre Mühen
Den “Stacktrace” können Sie unter Delphi derzeit leider nicht erhalten. Dieser wird über den Callback LL_NTFY_EXPRERROR_EX geliefert, der in Delphi nicht als Event umgesetzt ist.
Danke für die Information. Schade, dass Delphi derzeit außen vor ist.
Wann könnte ich mit der Implementierung für den Zugriff auf diese wichtige Information rechnen?
Oder gibt es eine Möglichkeit die Funktion/ Variable zu ermitteln, die nicht geparst werden konnte, wenn z.B. in einer “Cond” auf viele Variablen bezug genommen wird?
Aktuell besteht leider keine Möglichkeit den Inhalt der Felder zu ermitteln, die nicht geparsed werden können.
Sie können aber gerne Ihren Vorschlag in unserem Feature-Portal eintragen. Möglicherweise finden Sie diese in einer zukünftigen Version wieder.
Zum Feature-Portal:
https://www.combit.net/en/reporting-tool/suggestions/
Vielen Dank!
Wie funktioniert dann die Anzeige im Designer? Dort gibt es zum Fehler (Bild linke Seite) einen Eintrag (Bild rechte Seite). Dieser Fehler wird, so mein Verständnis, beim Parsen des Feldinhaltes erzeugt, gespeichert und ausgegeben. Genau dieser geparste Fehler wird benötigt und liegt auch vor.
Verstehe ich Sie richtig, daß diese vorliegende Information nicht nach außen gereicht werden kann?
vielen Dank
Die Information kann und wird nach außen gegeben, allerdings eben über eine Notification, die die VCL derzeit noch nicht umsetzt. Dies hängt auch mit den beteiligten Datentypen zusammen, die in Delphi nicht-trivial zu verarbeiten sind.
Wenn die Umsetzung für Sie sehr dringend ist kann ich Ihnen gerne die beteiligte Struktur dokumentieren und Sie könnten selbst versuchen, die VCL entsprechend zu erweitern. Alternativ bieten wir dringende Erweiterungen gerne auch als kostenpflichtige Anpassung an. Wenn es nicht ganz so dringend ist ist das Feature-Portal ein guter Ort für einen Erweiterungsvorschlag.
Guten Tag Herr Bartlau,
vielen Dank für das Angebot. Gerne nehme ich es an und die damit verbundene Herausforderung.
Ich danke Ihnen und Herrn Preuschoff für die Unterstützung
Sie müssen analog zum TNtfyErrorEvent einen neuen Event TNtfyErrorExEvent definieren:
TNtfyErrorEvent = procedure(Sender: TObject; ...) of object;
Dann fügen Sie in NtfyCallback einen neuen case für LL_NTFY_EXPRERROR_EX hinzu. Sie erhalten in lParam einen Zeiger auf eine Struktur, die in C++ so aussieht:
struct scLlNtfyExprErrorEx
{
UINT _nSize;
LPCWSTR _pszExpr;
LPCWSTR _pszError;
const VARIANT* _pvHierarchy; // array of strings
};
Der Knackpunkt hierbei ist der letzte Member, ein Zeiger auf ein VARIANT-Array, das die verschiedenen Zeilen der Baumstruktur enthält. Hier ist ein Beispiel, wie das vielleicht unter Delphi funktionieren könnte. Sie brauchen die Inhalte des Arrays nicht freizugeben, das wird auf unserer Seite gemacht. Sobald Sie aus dem VARIANT-Array eine “normale” Delphi-Datenstruktur erstellt haben (eine Stringliste oder ein Array) können Sie diese dann in den Event geben, das ist das ... in der Eventdeklaration oben, den konkreten Aufruf können Sie sich per Copy/Paste dann von einem der anderen Events kopieren.
Melden Sie sich gerne noch einmal mit Detailfragen. Andere Anwender würden sich sicher freuen, wenn wir die Umsetzung im Erfolgsfall in den Standardcode mitaufnehmen könnten.
Wunderbar, nur welche Nummer liegt hinter LL_NTFY_EXPRERROR_EX?
derzeit ist LL_NTFY_EXPRERROR = 51;
Die Konstante ist in der Delphi-Deklarationsdatei enthalten:
LL_NTFY_EXPRERROR_EX = 110;Vielen Dank für die rasche und gute Unterstützung.
Herr Bartlau,
das Event mit der Nummer 110 wird in der verwendeten Version 22 von L&L nicht ausgelöst.
Könnte es sich um eine andere Nummer handeln? Die Deklaration von LL_NTFY_EXPRERROR_EX ist leider nicht auffindbar.
vielen Dank
Oh, das war dann ein Missverständnis 
- das Event haben wir in LL23 neu aufgenommen, mir war nicht bewusst, dass Sie mit der Version 22 unterwegs sind. Kommt ein Update der Applikation in Frage?
Stimmt, ich vergaß auf die Version hinzuweisen.
Leider kommt derzeit kein Update der Aplikation in Frage.
Hinweis: im Handbuch “Programmierer Referenz” zur Version 24 befindet sich kein Hinweis zu LL_NTFY_EXPRERROR_EX
Ja, das Feature ist derzeit für alle Sprachen außer .NET noch undokumentiert, daher hatte ich Ihnen oben die Beschreibung reingepackt 
. Wir halten dies gelegentlich so, um noch Änderungen an Strukturen, Interfaces und APIs vornehmen zu können. Auch das Datenprovider-Interface war über drei Versionen undokumentiert, ehe wir es für C++ freigegeben haben. Bei LL_NTFY_EXPRERROR_EX würde ich aber keine Änderungen mehr erwarten, die Schnittstelle ist seit LL23 stabil und wird voraussichtlich mit LL25 auch dokumentiert werden.
Demzufolge besteht keine Möglichkeit in der L&L Version22 an die Information, “Fehler beim Parsen des Ausdrucks …”, zu gelangen ohne auf eine nächst höhere Version zu gehen, oder 
?