PureBoard

Ich blicks grad überhaupt nicht.
Gibt es diesen Bug nun oder ist der mittlerweise ausgebüglet und die aktuelle 3.92 -version stabil (in der hinsicht)?

PB über Smart-Update aktualisieren und dann aus
http://www.purebasic.com/beta/
die Libs manuell noch ins PB-Ordner-Libs kopieren.

Dann klappt alles.

(Vorsichtige Nachfrage)
Das heisst, das es keine Probleme mit linked Liste in 3.92 gibt ....?
(Wäre der Killer für mein aktuelles Projekt...)

Keine Probleme würd ich nicht sagen, die können immer wieder kommen. Mir ist aktuell ein Problem bei LLs bekannt welches auch in der neuesten Version noch unbehoben ist. Allerdings tritt dieser Fehler sehr selten auf (bisher erst 1 mal bei meinen Codes) und lässt sich zwar auch leicht umgehen, nervig ist es aber schon wenn man 3 Stunden Fehler sucht und es keine gibt sondern PB eben diesen Bug verschuldet...

Um den Fehler etwas zu beschreiben: Sieht eigentlich ganz logisch aus. Die erste Zeile geht zum Objekt welches in der Long-Variable mouse\following_object gespeichert wurde. Dann MÜSSTE eigentlich dieses Object angewählt sein. So ist es aber scheinbar nicht. Denn es treten sonderbare Fehler auf die ich mir nicht erklären kann. Erst wenn die 2te Zeile dazu kommt, wobei einem Wert der gleiche Wert wieder zugewiesen wird (also eigentlich unnötig und ohne Auswirkung) klappt alles so wie es soll. Seltsam, seltsam, also so ganz Fehlerfrei ist die LL nicht und wird sie wohl nie sein.
Ich hab den Fehler schon vor mehreren Monaten im englischen Forum gepostet und keine Antwort bekommen. Scheinbar kann dort auch keiner nachvollziehen wieso diese merkwürdigen Verhaltensänderungen auftreten wenn man die 2te unnötige Zeile rauslässt...

Na gut, das hält sich ja in gewissen grenzen...
Damit kann ich leben.

Vielen Dank für die Info

Kann nicht mal jemand ein ultimatives LinkedList()-Beispiel schreiben, das alle LinkedList-Befehle mindestens einmal aufruft, bestimmte Konstellationen testet (z.B. Löschen aller Elemente, Austauschen von Elementen usw.), die ganzen Rückgabeadressen prüft und alles das testet, was die LinkedLists laut Dokumentation können müsen? Quasi als Benchmark (mit Ergebniss-Protokoll) für die PB-User und für Fred. Dann braucht man das nur auszuführen und sieht sofort, was in der aktuellen Version wieder nicht klappt oder ob alles fehlerfrei funktioniert....

Lebostein hat geschrieben:Kann nicht mal jemand ein ultimatives LinkedList()-Beispiel schreiben, das alle LinkedList-Befehle mindestens einmal aufruft, bestimmte Konstellationen testet ....

Warum ist dieser 'jemand' nicht Lebostein?

Lebostein hat geschrieben:Kann nicht mal jemand ein ultimatives LinkedList()-Beispiel schreiben,

Gut Frage. Warum schreibst du keins?

GPI hat geschrieben:Gut Frage. Warum schreibst du keins?

Dazu sollte man sich schon mit den ganzen LL-Befehlen und deren Funktionsweise auskennen. Außerdem wäre Hintergrundwissen (was passiert im Speicher usw.) bestimmt auch nicht verkehrt. Leider fehlt mir beides bzw. hab ich bisher nur an der Obefläche gekratzt (ein paar Addelements() hier und ein paar Selectelements() da....). Ich glaub ich bin da der falsche....

Lebostein hat geschrieben:Kann nicht mal jemand ein ultimatives LinkedList()-Beispiel schreiben, das alle LinkedList-Befehle mindestens einmal aufruft, bestimmte Konstellationen testet (z.B. Löschen aller Elemente, Austauschen von Elementen usw.), die ganzen Rückgabeadressen prüft und alles das testet, was die LinkedLists laut Dokumentation können müsen? Quasi als Benchmark (mit Ergebniss-Protokoll) für die PB-User und für Fred. Dann braucht man das nur auszuführen und sieht sofort, was in der aktuellen Version wieder nicht klappt oder ob alles fehlerfrei funktioniert....

Nein, aus dem einfachen Grund dass Bugs meist immer in den sonderbarsten Fällen auftreten. Also in Sonderfällen und nicht im Normalfall. Demnach würde das überhaupt nichts bringen. Mein Bug etwa, etwas weiter oben beschrieben, tritt NUR in diesem einen Programm und nur da so auf. Wieso - keine Ahnung. Aber finden tut man solche Bugs eben nur in richtigen Anwendungen und nicht in Beispielcodes, jedenfalls ist die Chance im Erstgenannten wesentlich höher.