In LL15 haben wir bei Auswertungen als Seitenwechselnbedingung eine Formel im Format “Evaluate(Report.PageBreakCondition)==True” verwendet. PageBreakCondition enthält dabei einen dynamischen Text-Ausdruck wie z.B. “1==1”. Mit dem Update auf LL18 funktioniert diese Seitenwechselbedingung nicht mehr. Wird jedoch anstatt der Variable Report.PageBreakCondition derselbe inhaltliche Wert als Text verwendet (z.B Evaluate(“1==1”)==True) würde die Bedingung funktionieren.
Interessanterweise wird unten im Formelediter mit der problematischen Formel nichts angezeigt. Bei einem Einsetzten desselben Ausdrucks als Text, wird jeodch korrekt “True” angezeigt.
In der Update Doku haben wir keine Hinweise darauf gefunden, dass das Verhalten zwischen LL15 und LL18 geändert wurde. Weiss hier jemand mehr dazu? Gibt es einen Workaround, wie dynamische Ausdrücke für Seitenumbruchbedingungen verwendet werden können? Die Umbruchbedingung muss dynamisch durch den Benutzer gesteuert werden können (im Programmverhalten).
Die erwähnten Ausdrücke wurden für die Erklährungen im Beitrag vereinfacht. “True” kann nicht direkt eingesetzt werden, da im konkreten Anwendungsbeispiel der Ausdruck Bezug auf die Daten nimmt. Mit dem Einsatz des Ausdrucks “len(Position.Nummer) == 1 and Position.RowType==0” für die genannte Variable Report.PageBreakCondition erreichten wir, dass bei bestimmten Positionen ein Seitenumbruch ausgelöst wurde. Dies funktioniert aktuell leider nicht mehr.
Was können wir tun, damit der Seitenumbruch in Abhängkeit zur gedruckten Position wieder funktioniert?
irgendwie verstehe ich die Problematik gar nicht - warum nicht einfach die Formel selber bei der Seitenumbruchsbedingung angeben - also ohne Stringinhalt für eine Variable und ohne Evaluate()? Das ist doch viel übersichtlicher/klarer und für den Anwender besser zu verstehen. Wenn es partout eine Variable sein soll würde ich das in eine Benutzervariable packen, auch dann wird das funktionieren und man hat die Info, was da passiert da wo sie hingehört - im Designer. Oder übersehe ich etwas?
Hallo Herr Schwarze und Danke für die rasche Antwort
Wir können die Formel nicht direkt angeben, da diese dynamisch ist. Der Benutzer kann im Programm (ausserhalb von LL) angeben, wie er den Seitenumbruch gerne hätte. Damit können wir 1 Layout zur Verfügung stellen, anstatt 3 (bei drei Benutzer-Möglichkeiten für Seitenumbrüche). Aus diesen Grund verwenden wir Evaluate().
Ihr Vorschlag zum Verpacken des Ausdrucks “Evaluate(Report.PageBreakCondition)” in eine Benutzervariable haben wir gleich getestet. Leider funktioniert auch das nicht. Im Formeleditor wird unten beim Evaluierungsresultat der Formel nichts angezeigt. Dies scheint auch das Problem zu sein, wesshalb die Seitenumbruchsbedingung mit Evaluate() nicht mehr funktioniert.
Neue Erkenntnisse
Zu Testzwecken wurde ein neues Textobjekt mit den nachfolgenden Zeilen definiert:
Die erste Zeile zeigt wie erwartet den Ausdruck der übergebenen Formel an. Die zweite Zeile zeigt jedoch “True” an. Liegt möglicherweise hier das Problem, bzw. wie kann dieser Unterschied erkährt werden?
Vielleicht nicht die eleganteste Lösung - warum nicht einfach die drei verschiedenen Umbruchsmöglichkeiten als Variable “WrapType” oder so übergeben und dann
Cond(WrapType==1, len(Position.Nummer) == 1 and Position.RowType==0,Cond(WrapType==2,…))
verwenden? Das andere wäre ja irgendwie ein doppeltes Evaluate (erst aus dem String eine Formel, und die dann nochmal), das wird vermutlich Probleme machen. Dass da NULL rauskommt wundert mich zwar auch, aber das obere fände ich ohnehin immernoch besser, als die LL-Formel in einer Textvariablen hart zu codieren.
Ihr Lösungsvorschlag konnten wir erfolgreich testen, vielen Dank dafür.Mit der Übergabe von “WrapType==1” verändern wir aber den Datentyp von bisher String auf neu Integer. Dies würde dazu führen, dass sämtliche von Kunden angepassten Layouts nicht mehr funktionieren würden. Alternativ könnten wird den Datentyp auch bei String belassen, was aber zu Ausdrücken wie z.B. “Cond(WrapType==“1”, len(Position.Nummer) == 1 and Position.RowType==0,Cond(WrapType==“2”,…))” führen würde. Dies würden wir gerne vermeiden falls möglich.
@combit: Gibt es eine Möglichkeit die aktuelle Implementierung mittels Evaluate() beizubehalten, bzw. wie kann die Verhaltensänderung erklährt werden? Was müssten wir tun, damit mittels Evaluate() wieder dynamische, logische Ausdrücke verwendet werden könnten?
Es sieht danach aus, dass in der alten Implementierung der Evaluate-Funktion ein Fehler war, da die eine Stufe zu weit gerechnet hat.
Wenn Sie zwingend das alte Verhalten wieder benötigen, würde ich Sie bitten, sich mit uns bezüglich einer Anpassung in Verbindung zu setzen, wir werden dann prüfen ob das alte Verhalten, in dem Rahmen per Option wiederherstellbar ist.
Besten Dank für den konstruktiven Lösungsvorschlag und die Erklährung zum beschriebenen Verhalten.Wir werden unsere Auswertungen wie im Beitrag vom 15.04.2015 10:06:05 beschrieben anpassen, jedoch aus Kompatibilitätsgründen einen String-Datentypen einsetzen. Eine Sonderanpassung für uns ist nicht nötig, besten Dank für das Angebot.
