Seite 1 von 2
Problem mit Update von PB6.20-win-x86 auf PB6.21-win-x86
Verfasst: 13.08.2025 14:21
von techniker
Hallo,
ich wollte heute PB auf 6.21 (win, x86) hochziehen.
Beim Kompilieren mehrerer lauffähiger Projekte erhalte ich bei großen If-Schleifen mit mehreren ElseIf-Zweigen
Fehler in der Form "Zeile xyz: Unfinished splitted line". Mit PB 6.20 gibt es diese Fehlermeldung nicht.
Kann das noch jemand bestätigen?
Bug?
Neue Restriktion?
Leider ist der Code sehr umfangreich, um ihn hier zu posten. Das Kleinste Projekt besteht aus über 160'000 Zeilen.
// Moved from "Bugs" to "Allgemein" (Kiffi)
Re: Problem mit Update von PB6.20-win-x86 auf PB6.21-win-x86
Verfasst: 13.08.2025 14:40
von techniker
Code: Alles auswählen
Define a.i, b.i, c.i, d.i
Define s1.s
If a And
a And
(b Or
b Or
(c And c)) And
((a And
Not b And
Not b And
((c < 1000000 And d) Or
(c < 1000000 And d) Or
(Len(s1) < 8 And d) Or
(Len(s1) < 10 And d) Or
(a = 1 And Len(s1) < 12) Or
(a = 1 And Len(s1) >= 12 And Not b) Or
(a = 2 And Len(s1) < 5) Or
(a = 2 And Len(s1) >= 5 And Not b) Or
(a = 3 And Len(s1) < 5) Or
(a = 3 And Len(s1) >= 5 And Not b) Or
a = 0 Or
(100 < 1 And d) Or
(100 < 1 And d))) Or
; noch mehr Bedingungen blablabla
(Not a And
(a Or b) And
(a = 1 And Len(s1) < 12) Or
(a = 1 And Len(s1) >= 12 And Not a) Or
(a = 2 And Len(s1) < 5) Or
(a = 2 And Len(s1) >= 5 And Not a) Or
(a = 3 And Len(s1) < 5) Or
(a = 3 And Len(s1) >= 5 And Not a) Or
a = 0))
Debug 0815
EndIf
Ich habe nun einen Programmteil anonymisiert und sinnfrei durch ein paar Variablen ersetzt.
Ob die Abfrage Sinn ergibt oder nicht ist hier NICHT das Thema.
Syntaktisch ist die IF-Schleife korrekt und sollte keinen Fehler erzeugen.
Re: Problem mit Update von PB6.20-win-x86 auf PB6.21-win-x86
Verfasst: 13.08.2025 16:34
von Bisonte
mir ist aufgefallen, wenn man das Feature mit den Parametern über mehrere Zeilen nutzt, dürfen seit 6.21 keine leerzeilen mehr dazwischen sein.
und in 6.20 ging noch
aber ob das jetzt ein Bug oder ein Feature darstellen soll.... wer weiss es

Re: Problem mit Update von PB6.20-win-x86 auf PB6.21-win-x86
Verfasst: 13.08.2025 16:41
von techniker
Danke für den Workaround!
In der Tat sind die Leerzeilen INNERHALB einer Bedingung das Problem..!
Funktioniert:
Code: Alles auswählen
Define a.i, b.i, c.i, d.i
Define s1.s
If a And
a And
(b Or
b Or
(c And c)) And
((a And
Not b And
Not b And
((c < 1000000 And d) Or
(c < 1000000 And d) Or
(Len(s1) < 8 And d) Or
(Len(s1) < 10 And d) Or
(a = 1 And Len(s1) < 12) Or
(a = 1 And Len(s1) >= 12 And Not b) Or
(a = 2 And Len(s1) < 5) Or
(a = 2 And Len(s1) >= 5 And Not b) Or
(a = 3 And Len(s1) < 5) Or
(a = 3 And Len(s1) >= 5 And Not b) Or
a = 0 Or
(100 < 1 And d) Or
(100 < 1 And d))) Or
(Not a And
(a Or b) And
(a = 1 And Len(s1) < 12) Or
(a = 1 And Len(s1) >= 12 And Not a) Or
(a = 2 And Len(s1) < 5) Or
(a = 2 And Len(s1) >= 5 And Not a) Or
(a = 3 And Len(s1) < 5) Or
(a = 3 And Len(s1) >= 5 And Not a) Or
a = 0))
ElseIf a And
b And
c
Debug 0815
EndIf
Funktioniert NICHT:
Code: Alles auswählen
Define a.i, b.i, c.i, d.i
Define s1.s
If a And
a And
(b Or
b Or
(c And c)) And
((a And
Not b And
Not b And
((c < 1000000 And d) Or
(c < 1000000 And d) Or
(Len(s1) < 8 And d) Or
(Len(s1) < 10 And d) Or
(a = 1 And Len(s1) < 12) Or
(a = 1 And Len(s1) >= 12 And Not b) Or
(a = 2 And Len(s1) < 5) Or
(a = 2 And Len(s1) >= 5 And Not b) Or
(a = 3 And Len(s1) < 5) Or
(a = 3 And Len(s1) >= 5 And Not b) Or
a = 0 Or
(100 < 1 And d) Or
(100 < 1 And d))) Or
(Not a And
(a Or b) And
(a = 1 And Len(s1) < 12) Or
(a = 1 And Len(s1) >= 12 And Not a) Or
(a = 2 And Len(s1) < 5) Or
(a = 2 And Len(s1) >= 5 And Not a) Or
(a = 3 And Len(s1) < 5) Or
(a = 3 And Len(s1) >= 5 And Not a) Or
a = 0))
ElseIf a And
b And
c
Debug 0815
EndIf
Auch Kommentare sind nicht mehr zulässig:
Code: Alles auswählen
Define a.i, b.i, c.i, d.i
Define s1.s
If a And
a And
(b Or
b Or
(c And c)) And
((a And
Not b And
Not b And
((c < 1000000 And d) Or
(c < 1000000 And d) Or
(Len(s1) < 8 And d) Or
(Len(s1) < 10 And d) Or
(a = 1 And Len(s1) < 12) Or
(a = 1 And Len(s1) >= 12 And Not b) Or
(a = 2 And Len(s1) < 5) Or
(a = 2 And Len(s1) >= 5 And Not b) Or
(a = 3 And Len(s1) < 5) Or
(a = 3 And Len(s1) >= 5 And Not b) Or
a = 0 Or
(100 < 1 And d) Or
(100 < 1 And d))) Or
(Not a And
(a Or b) And
(a = 1 And Len(s1) < 12) Or
(a = 1 And Len(s1) >= 12 And Not a) Or
(a = 2 And Len(s1) < 5) Or
(a = 2 And Len(s1) >= 5 And Not a) Or
(a = 3 And Len(s1) < 5) Or
(a = 3 And Len(s1) >= 5 And Not a) Or
a = 0))
ElseIf a And
b And
; Kommentar
c
Debug 0815
EndIf
Das ist ein herber Rückschritt im Bezug auf Lesbarkeit und Dokumentierung und m.M.n.
eindeutig ein Bug.
Re: Problem mit Update von PB6.20-win-x86 auf PB6.21-win-x86
Verfasst: 13.08.2025 17:12
von STARGÅTE
Nein, es ist kein Bug, sondern wurde absichtlich geändert wegen dieses Problems:
Interesting compiler behavior with line continuation
(auch wenn man diese Änderung schlecht findet, macht es sie noch nicht zum Bug)
Vor PB 6.21 hat der Compiler bei solche Ausdrücken nicht gemeckert und man ging davon aus, dass alles ok sei:
Code: Alles auswählen
Define String.s
Define String.s
; String Erstellen
String = "Erste Zeile des Strings " +
"Zweite Zeile des Strings " +
; Console Öffnen
OpenConsole()
PrintN(String)
Input()
Stattdessen aber hatte man im Code ein "+" zu viel in Zeile 5, was dazu führte, dass der Ausgabe eine "1" vom Resultat von OpenConsole() angehängt wurde:
Erste Zeile des Strings Zweite Zeile des Strings 1
Daher müssen Zeilenfortsetzungen nun ohne Leerzeilen/Kommentare sein.
Re: Problem mit Update von PB6.20-win-x86 auf PB6.21-win-x86
Verfasst: 13.08.2025 17:20
von techniker
Das ist ansichtssache und könnte so auch gewollt sein.
In dem Fall wäre eine Option sinnvoller gewesen, als harte Änderung. Finde ich absolut nicht gut..
In meinem Fall habe ich nun jede Mende Arbeit und das Problem, dass ich wichtige Kommentare entfernen muss.
Diese Entscheidung ist nicht durchdacht und ein eindeutiger Schnellschuss. Damit werden etliche Codes nicht mehr lauffähig sein.
Re: Problem mit Update von PB6.20-win-x86 auf PB6.21-win-x86
Verfasst: 13.08.2025 17:39
von STARGÅTE
techniker hat geschrieben: 13.08.2025 17:20
Das ist ansichtssache und könnte so auch gewollt sein.
In dem Fall wäre eine Option sinnvoller gewesen, als harte Änderung. Finde ich absolut nicht gut..
In meinem Fall habe ich nun jede Mende Arbeit und das Problem, dass ich wichtige Kommentare entfernen muss.
Diese Entscheidung ist nicht durchdacht und ein eindeutiger Schnellschuss. Damit werden etliche Codes nicht mehr lauffähig sein.
Ich kann dein Frust nachvollziehen. Ein früheres Update, wonach die einfachen Anführungszeichen nur noch ein Zeichen beinhalten dürfen, hatte meine Code auch kaputt gemacht. Damals musste ich aus 'ABC' z.B. 'A'<<32+'B'<<16+'C' machen.
Allerdings war ich damals wohl der einzige der das nutzte.
Genauso ist es in deinem Fall. Ich habe bis zu deine Post noch nie einen Code gesehen, der seine Zeilenfortsetzung derart strukturieren wollte (mit Leerzeilen oder gar Kommentaren).
Re: Problem mit Update von PB6.20-win-x86 auf PB6.21-win-x86
Verfasst: 13.08.2025 19:48
von HeX0R
STARGÅTE hat geschrieben: 13.08.2025 17:39
Ich kann dein Frust nachvollziehen. Ein früheres Update, wonach die einfachen Anführungszeichen nur noch ein Zeichen beinhalten dürfen, hatte meine Code auch kaputt gemacht. Damals musste ich aus 'ABC' z.B. 'A'<<32+'B'<<16+'C' machen.
Allerdings war ich damals wohl der einzige der das nutzte.
Nein, andere (ich) haben darüber aber eher im Stillen geschimpft

Re: Problem mit Update von PB6.20-win-x86 auf PB6.21-win-x86
Verfasst: 13.08.2025 20:05
von techniker
Bei einem Programm habe ich eine sehr komplexe Fallentscheidung aus If/Elseif. Es werden insgesamt 52 Variablen geprüft - wobei immer nur bis zu etwa 20 Variablen auf einmal. Diese haben unterschiedliche Wertigkeit - je nach Kombination (darum ElseIf) und ergeben 37 Fälle. Wobei mehrere Variablen-Kombinationen den gl. Fall ergeben können. Die If-Schleife ist somit um die 800 Zeilen lang.
Wie soll man eine solche Monster-Abfrage ohne Kommentare dokumentieren, so dass man nach ein paar Wochen immer noch durchblickt?
Re: Problem mit Update von PB6.20-win-x86 auf PB6.21-win-x86
Verfasst: 13.08.2025 21:20
von STARGÅTE
techniker hat geschrieben: 13.08.2025 20:05
Bei einem Programm habe ich eine sehr komplexe Fallentscheidung aus If/Elseif. Es werden insgesamt 52 Variablen geprüft - wobei immer nur bis zu etwa 20 Variablen auf einmal. Diese haben unterschiedliche Wertigkeit - je nach Kombination (darum ElseIf) und ergeben 37 Fälle. Wobei mehrere Variablen-Kombinationen den gl. Fall ergeben können. Die If-Schleife ist somit um die 800 Zeilen lang.
Wie soll man eine solche Monster-Abfrage ohne Kommentare dokumentieren, so dass man nach ein paar Wochen immer noch durchblickt?
Du meinst, deine Abfrage für das If ist selbst schon 800 Zeilen (mit Umbrüchen) lang? Das das der Compiler überhaupt mitmacht.
Wäre es bei sowas nicht besser mit Prozeduren zu arbeiten, die die einzelnen Blöcke der And- und Or-Abfragen Strukturieren?
Check_Main() hätten dann sowas wie:
Code: Alles auswählen
ProcedureReturn Bool( Check_Sub1() And ( Check_Sub2() Or Check_Sub2() ) )
Und so weiter. Viele Unterabfragen ähneln sich vielleicht sogar, sodass du sogar Zeilen sparst.
Da du dein Code ja für ein Versionsupdate vermutlich eh umschreiben musst, wäre das eine Überlegung wert.
Zudem lassen sich die Unterprozeduren viel leichter Debuggen. Bei deiner Monster-If-Abfrage hast du doch keine Chance dort irgendwo mal zu gucken/checken, welcher And/Or-Fall-Pfad als "Wahr" ausgewertet wurde, weil der Debugger es ja als eine Zeile erkennt?
PS:
if-schleife.de