Was ist eigentlich mit dem Listen-bug in 3.92?
Was ist eigentlich mit dem Listen-bug in 3.92?
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)?
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.
http://www.purebasic.com/beta/
die Libs manuell noch ins PB-Ordner-Libs kopieren.
Dann klappt alles.
CodeArchiv Rebirth: Deutsches Forum Github Hilfe ist immer gern gesehen!
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...
Um den Fehler etwas zu beschreiben:
Code: Alles auswählen
ChangeCurrentElement(inv_object(), mouse\following_object)
inv_object()\use = inv_object()\use ;make this line a Comment and it won't workIch 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...
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....
Warum ist dieser 'jemand' nicht Lebostein?Lebostein hat geschrieben:Kann nicht mal jemand ein ultimatives LinkedList()-Beispiel schreiben, das alle LinkedList-Befehle mindestens einmal aufruft, bestimmte Konstellationen testet ....
Siehste! Geht doch....?!
PB*, *4PB, PetriDish, Movie2Image, PictureManager, TrainYourBrain, ...
PB*, *4PB, PetriDish, Movie2Image, PictureManager, TrainYourBrain, ...
Gut Frage. Warum schreibst du keins?Lebostein hat geschrieben:Kann nicht mal jemand ein ultimatives LinkedList()-Beispiel schreiben,
CodeArchiv Rebirth: Deutsches Forum Github Hilfe ist immer gern gesehen!
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....GPI hat geschrieben:Gut Frage. Warum schreibst du keins?
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.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....