Neu Darstellungsbedingung "not lastpage()" seit 1.6 fehlerhaft?

[MarioKersting]

Hallo zusammen,
seit dieser Woche haben wir uns endlich an das Update auf die >1.6er Version gewagt und bisher nur kleinere "kosmetische" Fehler.

Wir drucken einen Hinweis auf unsere internen Auftragszettel, wenn der Auftrag aus mehreren Seiten besteht, es soll dann "Fortsetzung Seite 2" auf der ersten Seite stehen.
Das ist relativ einfach über eine Textebene gelöst, die eben nur eingeblendet werden soll wenn es mehr als eine Seite gibt, bisher funktionierte das mit "Darstellungsbedingung: not lastpage()".
Seit dem Update wird aber auf JEDEN Auftrag "Fortsetzung Seite 2" gedruckt, weil die Bedigung "not lastpage()" plötzlich dauerhaft "true" ist, auch wenn es nur ein kleiner Auftrag mit einem Artikel ist der auf eine Seite passt.
Gibt es eine bessere Lösung dafür?

 

[Verkäuferlein]

Ob die Funtkion tatsächlich nicht mehr funktioniert oder irgendwie anders umgesetzt werden muss, kann ich Dir nicht sagen.

Wir haben diese "Fortsetzung..." aber sowieso aus unseren Vorlagen entfernt und schreiben unten einfach "Seite X / Y", damit ist dann ja auch klar, wieviele Seiten der Beleg hat und das er vermutlich auf der 2. Seite fortgesetzt wird, wenn man auf Seite 1/2 ist.

Ich weiß nicht, ob das standardmäßig in den Vorlagen enthalten ist, aber wir haben also ein TeFeld mit dem Inhalt:

"Seite: " +Page$()+" / " +TotalPages$()

 

[dazligth]

Ja geht uns auch so. Ging in der 1.5 noch, jetzt in 1.7 nicht mehr.
Wenn es nur eine Seite gibt und somit die erste Seite auch die letzte Seite ist, ist LastPage() = False obwohl es true sein sollte.

Hab versucht es hinternrum durch die Brust zu lösen mit:
TotalPages$() <>"1" AND NOT TotalPages$() = Page$()

Musste aber auch feststellen, dass auch Page$() im Kontext der Darstellungsbedingungen nicht funktioniert.
Es sieht so aus, dass die Werte im Hintergrund initialisiert aber nicht vergeben/berechnet werden.

 

[Verkäuferlein]

Ja geht uns auch so. Ging in der 1.5 noch, jetzt in 1.7 nicht mehr.
Wenn es nur eine Seite gibt und somit die erste Seite auch die letzte Seite ist, ist LastPage() = False obwohl es true sein sollte.

Hab versucht es hinternrum durch die Brust zu lösen mit:
TotalPages$() <>"1" AND NOT TotalPages$() = Page$()

Musste aber auch feststellen, dass auch Page$() im Kontext der Darstellungsbedingungen nicht funktioniert.
Es sieht so aus, dass die Werte im Hintergrund initialisiert aber nicht vergeben/berechnet werden.

Zwischenzeitlich habe ich mir das mal genauer angeguckt und wenn ich das richtig sehe, ist das ein gewolltes Verhalten von List & Label, da z.B. lastpage() wohl nur im Zusammenhang mit Tabellen / Berichtscontainern ausgewertet wird.

Siehe auch:
https://docu.combit.net/designer/de/index.html#!Documents/darstellungsbedingungenmitlastpage.htm

Keine Ahnung, ob JTL da irgendwie Einfluss drauf nehmen kann, wie das in der Wawi genutzt wird. Auf jeden Fall wäre es gut die Darstellungsbedingungen etwas flexibler zu machen.

Das Problem bei Deiner "Formel" ist, dass TotalPages$() und Page$() eine Zeichenkette (String) zurückgeben und keine ganze Zahl (Integer). Du müsstest also entweder die Ausgabe noch in einen Integer wandeln, um dann mit Größer als oder Kleiner als vergleichen zu können oder eine andere Form des String-Vergleichs benutzen. Allerdings weiß ich nicht, ob TotalPages$() da überhaupt einen richtigen Wert zurückgibt, bei mir ist das immer nur 0 in den Bedingungen.

Bei Page gibt es beide Funktionen, also Page() <- Integer und Page$() <- String, bei den anderen aber leider nicht.

 

[dazligth]

Zwischenzeitlich habe ich mir das mal genauer angeguckt und wenn ich das richtig sehe, ist das ein gewolltes Verhalten von List & Label, da z.B. lastpage() wohl nur im Zusammenhang mit Tabellen / Berichtscontainern ausgewertet wird.

Komisch ist dann schon warum es in der 1.5 noch funktioniert hat. Aber vielleicht hat List&Label was geändert.

TotalPages$() und Page$() eine Zeichenkette (String)

Ja schon klar, aber String mit String zu vergleichen sollte doch gehen. Funktioniert bei TotalPages$() <>"1" ja auch.
Das war ja der Sinn der Sache, da sehe ich dann nicht zwingend ein Problem, höchstens dass man vielleicht noch Klammern setzen müsste.

Allerdings weiß ich nicht, ob TotalPages$() da überhaupt einen richtigen Wert zurückgibt, bei mir ist das immer nur 0 in den Bedingungen.

Ja das ist das eigentliche Problem, wie ich oben schrieb. Die Werte sind alle mit 0 initialisiert und werden nicht "bei Ausführung" nicht für die Anzeige-Bedingungen ermittelt/befüllt. Denke das ist dann analog zu deinem Link von lastpage() und führt dann zum selben Ergbnis

 

[Verkäuferlein]

Dann komisch ist dann schon warum es in der 1.5 noch funktioniert hat. Aber vielleicht hat List&Label was geändert.

Die Doku ist ja für List&Label 28, vielleicht hat JTL die List&Label-Version hochgezogen.

Ja schon klar, aber String mit String zu vergleichen sollte doch gehen. Funktioniert bei TotalPages$() <>"1" ja auch.

Vielleicht wird das intern dann irgendwie in einen Integer umgewandelt, aber was ich mal gelernt habe, ist ein größer/kleiner Vergleich für einen (zwei) String(s) nicht möglich.

Ja das ist das eigentliche Problem, wie ich oben schrieb. Die Werte sind alle mit 0 initialisiert und werden nicht "bei Ausführung" nicht für die Anzeige-Bedingungen ermittelt/befüllt. Denke das ist dann analog zu deinem Link von lastpage() und führt dann zum selben Ergbnis

Das kann durchaus sein, dann würde der Boolean standardmäßig mit false und die Integer standardmäßig mit 0 initialisiert und erst im eigentlichen Projekt hochgezählt, nicht aber für die Darstellungsbedingungen.

Die Frage ist, ob JTL da was tun kann oder das halt mit Combit zu tun hat. Möglicherweise ist es aber auch ein Bug in der von JTL genutzten L&L-Version (aktuell 26) und in neueren Versionen (aktuell 28) schon wieder behoben.

 

[dazligth]

Hab auch Dinge wie ToNumber(TotalPages$()) ausprobiert.

Es liegt vielleicht auch an Laufzeiten und Rekursionsmechanismen. Man sieht in der Generierung der Vorschau. Das der Platzhalter TotalPages$ erst gefüllt wird wenn alle Seiten durchgeneriert sind. Ist auch logisch. Dann findet eine Art Rekursion statt in der diese Platzhalter nochmals ausgetauscht werden. Diese Rekursion findet dann aber nicht mehr für Darstellungsbedingungen statt, weil diese in einem vorherigen Durchlauf schon ausgewertet wurden und nicht neu auf den Prüfstand kommen.
So Mechanismen sind schwer zu Programmieren, weil man nicht sicher verhinderen kann, dass Zirkelbezüge vom User eingebaut werden. Dann wird nicht selten aus Vereinfachunggründen sowas eben einfach nicht erlaubt und gut.

Weiß nicht ob und wie JTL hier Einfluss nehmen kann.

Aber wie von dir erwähnt haben wir auch folgendes drin:

"Seite: " + Page$() + " / " + TotalPages$ ()

Hier gibt es eine Anzeigebedingung mit

Page() > 1

und der funktioniert auch. Damit kann man am Ende natürlich auch leben.

 

[dazligth]

Jedenfalls gibt es ein Ticket dazu wie ich gesehen habe.

https://issues.jtl-software.de/issues/WAWI-66688

 

[Verkäuferlein]

Hab auch Dinge wie ToNumber(TotalPages$()) ausprobiert.

Ich hatte es mit val(TotalPages$()) probiert, da kommt aber 0 raus.

Jedenfalls gibt es ein Ticket dazu wie ich gesehen habe.

https://issues.jtl-software.de/issues/WAWI-66688

Ja, das habe ich schon auf Beobachtung, allerdings weiß ich nicht wie genau das geprüft wurde oder ob es erstmal einfach nur als "Wunsch" notiert wurde.

Mit der 1.6 ist ja scheinbar die List & Label Version von 25 auf 26 angehoben worden, es gibt ja jetzt schon V27/28 von L&L.

Vielleicht behebt ja bereits die Versionsanhebung von L&L das Problem. Ich kann mir vorstellen, dass es bei der Berichtsgenerierung mitunter als Darstellungsbedingung sehr wichtig ist, ob man auf der letzten Seite ist oder nicht. Auf der anderen Seite ist natürlich auch klar, dass die ganze Vorlage erst einmal gerendert werden muss (und das nach jeder Veränderung), um diese Darstellungsbedingungen überhaupt auswerten zu können und deshalb nur der Berichtscontainer ausgewertet wird, weil da die Größe mit der Datenholung schon klar ist.

Hast Du mal getestet, ob die Darstellungsbedingung vielleicht auch nur im Designer nicht richtig (rekursiv) funktioniert und bei der richtigen Ausgabe berücksichtigt wird?

 

[Verkäuferlein]

So Mechanismen sind schwer zu Programmieren, weil man nicht sicher verhinderen kann, dass Zirkelbezüge vom User eingebaut werden. Dann wird nicht selten aus Vereinfachunggründen sowas eben einfach nicht erlaubt und gut.

Es gibt wohl eine Funktionalität die sich Multipass Processing nennt, wenn diese aktiviert ist, kann man es so konfigurieren, dass erst einmal die Ausgabe "durchgespielt" wird und dann z.B. die Variable am Ende der letzten Seite gesetzt wird.

So dass dann im 2. Durchlauf klar ist, welches die letzte Seite ist (allerdings gilt das dann ja auch nur für statische Designs), wenn man jetzt mit Darstellungsbedingung Lastpage() jeweils von mal 1 DIN A4 Seite Text einfügt, kommt es zu Deinem beschriebenen Effekt.

Infos dazu siehe hier:
https://forum.combit.net/t/using-lastpage-and-totalpages-functions/7730/7

 

[SebastianB]

Hi,
also: Wir haben keinen Einfluss darauf, was List&Label macht. Das Verhalten von LastPage und TotalPages entspricht aktuell halt der Beschreibung - das hat was damit zu tun, wie List&Label funktioniert - vereinfacht gesagt: Die "Tabellen" oder "Berichtscontainer" bestimmen am Ende des Tages wie lang die Ausgabe wird - und bis die nicht durch sind, weiß man also nicht, ob man auf der letzten Seite ist. Ich weiß, dass List&Label hier schon mehrfach am Verhalten der Funktion was geändert hat - ich meine wir hatten ein ähnliches Problem schonmal vor Jahren. Damals konnte man das Verhalten durch das Setzen von einem Kompatibilitätsflags wieder auf den alten Modus schalten - es kann sein, dass dieses Kompatibilitätsflag jetzt nach all den Jahren geflogen ist oder dass es fehlerhaft ist (wir haben an der Anbindung nichts geändert).
Am Ende des Tages bringt es aber nichts, gegen den Hersteller der Software mit solchen Flags zu "kämpfen": Man sollte also einen Weg finden, Vorlagen so zu bauen, dass die Funktionen nur im dokumentierten Kontext verwendet werden.
Vielleicht hilft es auch, mit einer zeitlichen Verkettung zu arbeiten, d.h. den Textblock der die Bedingen enthält zeitlich hinter den Berichtscontainer zu setzen (https://docu.combit.net/designer/de/index.html#!Documents/diezeitlicheverkettung.htm) - dann sollte er auch wissen, ob er auf der letzten Seite ist oder nicht.

 

[sah]

Hier ein Ticket dazu https://issues.jtl-software.de/issues/WAWI-66688
bitte voten, vielleicht kann auch auf Third-Party-Komponenten Einfluss ausgeübt werden.

 

[Verkäuferlein]

Hier ein Ticket dazu https://issues.jtl-software.de/issues/WAWI-66688
bitte voten, vielleicht kann auch auf Third-Party-Komponenten Einfluss ausgeübt werden.

Das bringt doch nichts, JTL kann da nichts beeinflussen.

Lies Dir nochmal Beitrag #10 und #11 in diesem Thread durch, da findest Du Möglichkeiten, wie Du es umsetzen kannst.

 

[lohkaes]

Hallo,

ich habe gerade mal folgenden Code getestet:

Cond(count(Page$())=0,"","Fortsetzung Seite " + Fstr$(Page() +1, "###") )

Kann das mal jemand bitte bei sich in den Vorlagen testen, ob hiermit das Problem mit der falschen Folgeseiten anzeige, gefixt ist?
Getestet in der Version 1.6.47.2

Gruß

 

[sah]

Leider nicht, die letzte Seite wird damit auch nicht erkannt.
Sollte man nicht direkt über die Darstellungsbedingung gehen?

 

[lohkaes]

Leider nicht, die letzte Seite wird damit auch nicht erkannt.
Sollte man nicht direkt über die Darstellungsbedingung gehen?

Hallo sah,

ich hab das jetzt gerade nochmals getestet. Bei mir ist es genauso wie es sein sollte. Wenn nur eine Seite vorhanden ist, wird der Text mit der Folgeseite nicht angezeigt, wenn es jedoch mehr als eine Seite ist
wird mir der Text mit der Folgeseite angezeigt. Auf der letzte Seite muss der Text ja auch nicht stehen.

Wenn ich deine Antwort nicht richtig verstanden habe, bitte nochmals erklären. Danke.

Gruß