Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
kilix
Anmeldungsdatum: 05.02.2022 Beiträge: 175
|
Verfasst am: 22.12.2022, 20:01 Titel: Fehler in FOR-Schleife |
|
|
Ich lese die Sätze einer Datei in einer FOR-Schleife ein. Dazu habe ich mit LOF() und recordLength ausgerechnet wie oft die Schleife zu durchlaufen ist. Das hat in 8 Testreihen in denen ich Datensätze erfasst und wieder eingelesen habe funktioniert. Beim neuntenmal habe ich zwar die Datensätze eingegeben aber nur der derste davon wurde gelistet.
Ich habe dann die For-Schleife auf DO mit LOOP UNTIL EOG geändert was klaglos funtioniert hat.
Code: |
'Fehlerversion:
FOR I = 1 TO LOF(fe)/recordLengthFE
GET #ffe, (I-1)*recordLengthFE+1, recordFE
' weitere eBefehle
NEXT
'richtige Version
DO
GET #ffe, (I-1)*recordLengthFE+1, recordFE
' weitere Befehle
LOOP UNTIL EOF(ffe)
|
Jetzt meine Fragen:
1) was war in der ersten Version falsch
2) was kann der Grund sein, dass es 8x funktioniert hat und beim 9.Mal nicht?
_________________ _________________ Grüße
kilix |
|
Nach oben |
|
 |
ThePuppetMaster

Anmeldungsdatum: 18.02.2007 Beiträge: 1839 Wohnort: [JN58JR]
|
Verfasst am: 22.12.2022, 23:45 Titel: |
|
|
auf anhieb ich ich dir das jetzt garnicht beantworten, aber was ich auf die schnelle gesehen habe: Bitte das EOF nicht an das UNTIL sondern an das DO koppeln. Grund: Wenn die Datei leer ist, durchläufst du die DO...Loop min. 1x, und löst damit einen Fehler aus. Wenn die EOF prüfung schon beim DO beginnt, wird noch vor dem ersten durchlauf geprüft, ob die datei leer ist und damit auch im zweifelsfall sofort exited.
Bezüglich der rechnung mit " / recordLength" ... gib doch mal direkt auf der konsole aus, was bei der division raus kommt. Vieleicht ist das garnicht 1,0 ... 2,0 .. 3,0 sondern ein 1,3 oder 5,2 und die rundung in ein integer würde aus 5,2 ein 5.0 und nicht ein 6.0 machen.
Print Str(LOF(fe)/recordLengthFE)
MfG
TPM _________________ [ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
Nach oben |
|
 |
kilix
Anmeldungsdatum: 05.02.2022 Beiträge: 175
|
Verfasst am: 23.12.2022, 08:01 Titel: |
|
|
Danke für den Hinweis DO LOOP betreffen!
Was die Berechnung LOF(fe)/recordLengthFE betrifft habe ich gestern dann auch noch überprüft. Tatsächlich erhält man eine Zahl mit Dezimalen. Ich könnte mir vorstellen, dass das eine eventuell mögliche Ursache sein könnte. Allerdings verstehe ich nicht warum das Problem dann nicht beim letzten Satz auftritt sondern schon früher und immer nach dem gleichen Satz. Ich habe nämlich nachdem ich die letzten 9 Sätze nicht sah diese noch einmal eingegeben. Trotzdem war immer nach dem gleichen Satz Ende.
Ich habe aber auch schon in einigen anderen Programmen ohne Probleme mit der FOR-Schleife gearbeitet. Allerdings habe ich das Ergebnis in eine Integer-Variable gespeichert und damit automatisch hinter dem Komma abgeschnitten. _________________ Grüße
kilix |
|
Nach oben |
|
 |
nemored

Anmeldungsdatum: 22.02.2007 Beiträge: 4688 Wohnort: ~/
|
Verfasst am: 23.12.2022, 17:06 Titel: |
|
|
Ich finde dieses Verhalten auch sehr mysteriös. Das hilft jetzt aber nicht weiter ...
Trotzdem noch etwas hoffentlich Konstruktives zum Thema:
Wenn der Fehler reprodizierbar ist, könntest du noch in jedem Durchlauf der FOR-Schleife ausgeben, welche Werte I und (I-1)*recordLengthFE+1 annimmt. Damit siehst du einerseits, wie lang die Schleife läuft (also ob sie zu früh beendet oder "nur" irgendwann fehlerhafte Werte einliest) und andererseits, ob sich der Dateizeiger jedesmal an der korrekten Position befindet. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
 |
kilix
Anmeldungsdatum: 05.02.2022 Beiträge: 175
|
Verfasst am: 23.12.2022, 17:26 Titel: |
|
|
Ja, irgendwie stoße ich immer wieder auf solche Dinge. Ein Freund aus dem Verein hat eine Internetapplikation für den Verband der Vereine geschrieben, er ist Profi auf diesem Gebiet. Er bat mich einen Teil davon zu testen und unbeabsichtigt stieß ich einige Male in sonderbare Fehler. Aber eigentlich soll das beim Test ja so sein .
Ich werde deinen Hinweis aufnehmen, es ist ja leicht möglich, dass die Dezimalen inrgendwie da hineinspielen.
Ich habe nun einmal die Schleife wieder auf DO LOOP geändert und konnte damit die Tests des Haupteils meiner Vereinssoftware fertig machen. Und, dass es so weit gekommen ist verdanke ich eurer Hilfe hier im Forum! _________________ Grüße
kilix |
|
Nach oben |
|
 |
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1278 Wohnort: Ruhrpott
|
Verfasst am: 23.12.2022, 18:54 Titel: |
|
|
@ kilix:
Vielleicht liegt der Fehler ja auch an einer ganz anderen Stelle. Hast du überprüft, ob die Datei auch wirklich (genau) die Länge <AnzahlDerDatensätze * Datensatzlänge> hat? Und haben alle Datensätze die richtige Länge und das richtige Format?
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
 |
kilix
Anmeldungsdatum: 05.02.2022 Beiträge: 175
|
Verfasst am: 23.12.2022, 21:00 Titel: |
|
|
hallo grindstone,
die Länge der Datei habe ich nicht überprüft sondern einfach genommen was LOF() gab. Die Recordlänge und Feldlängen sind absolut fix.
Ich habe jeweils 2 bis 12 Datensätze je Vereinsabend erfasst.
D.h. ich habe die Nummer des Abends eingestellt und dann die Datensätze dazu eingegeben. Wenn schon Datensätze vorhanden waren habe ich sie gelistet und die neuen dazu erfasst und dann alles gespeichert.
Das ging für 10 Abende gut erst beim 11. gab es Probleme. Ich habe den Abend noch einmal aufgerufen, das Programm zeigte mir aber nur den ersten von 10 eingegebenen Sätzen. Nachdem ich noch beim Testen war dachte ich, dass die Speicherung vielleicht nicht funktioniert hat und gabe die fehlenden Sätze noch einmal ein. Beim neuerlichen Aufrufen des Programmes und dieses Abends wurde mir wieder nur der erste Satz gezeigt.
Nach der Änderung von FOR NEXT auf DO LOOP wurden alle Sätze richtig angezeigt und zwar die zweimal erfassten auch zweimal.
Das Programm stoppte beim Listen immer nach dem gleichen Satz, so als ob dort eine Bruchstelle wäre. Aber weder dieser Satz noch der nächste, nicht mehr gelistete hatte irgend eine Auffälligkeit. Daher gehe ich davon aus, dass es ev. mit den oben genannten Dezimalen der Dateiendeberechnung zusammenhängt.
Ich muss ergänzen, dass die Datei keine fixe Größe hat, das mit jedem neuen Vereinsabend neue Datensätze eingegeben und gespeichert werden. _________________ Grüße
kilix |
|
Nach oben |
|
 |
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1278 Wohnort: Ruhrpott
|
Verfasst am: 24.12.2022, 23:02 Titel: |
|
|
Vielleicht ist es ja nur ein simpler Tippfehler. Code: | 'Fehlerversion:
FOR I = 1 TO LOF(fe)/recordLengthFE
GET #ffe, (I-1)*recordLengthFE+1, recordFE
' weitere eBefehle
NEXT | Du rufst die Daten aus einer Datei mit der Nummer ffe ab, die Anzahl der Datensätze berechnest du aber aus der Länge einer Datei mit der Nummer fe.
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
 |
kilix
Anmeldungsdatum: 05.02.2022 Beiträge: 175
|
Verfasst am: 25.12.2022, 11:57 Titel: |
|
|
Nein, das ist kein Tipfehler, ich habe die Datei so eröffnet:
Zitat: |
dim as Ulong recordLengthFE, ffe = FREEFILE
TYPE RecordTypeFE
Fech1 AS Byte
Fech2 AS STRING * 5
'
'
Fech12 AS Ulong
Fech13 AS STRING * 20
END TYPE
DIM recordFE AS RecordTypeFE
recordLengthFE = LEN(RecordTypeFE)
OPEN "\SVS\Dateien\FECH.DAT" FOR Binary ACCESS READ WRITE SHARED AS #ffe
|
Ich habe von Anfang an das este f für FREEFILE verwendet (ob das Sinn macht oder nicht ist ein andres Thema). Da verwendete ich fa, fs usw. und erkannte darin die Dateinummer. Für diese Datei bot sich auf Grund des Namens eben fe und daher ffe an. Alle anderen Variablen heißen daher nur xxxFE. _________________ Grüße
kilix |
|
Nach oben |
|
 |
nemored

Anmeldungsdatum: 22.02.2007 Beiträge: 4688 Wohnort: ~/
|
Verfasst am: 25.12.2022, 13:45 Titel: |
|
|
Dann sollte in der FOR-Zeile allerdings auch
Code: | FOR I = 1 TO LOF(ffe)/recordLengthFE |
stehen, sonst greifst du dort voraussichtlich auf die Länge der falschen Datei zu. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
 |
kilix
Anmeldungsdatum: 05.02.2022 Beiträge: 175
|
Verfasst am: 25.12.2022, 14:28 Titel: |
|
|
Ja, da hast du recht! Ich kann es aber nicht mehr nachvollziehen denn diese Programmversion habe ich nicht mehr. Ich habe zwar die Codezeilen aus dem Thread,oben, in das Programm kopiert und die aktuellen Zeilen ausgeblendet. Wie nach deiner Antwort nicht anders zu erwarten wurde gar nicht gelistet was mit dem was ich früher bekam nicht übereinstimmt. Früher bekam ich immer zu wenig gelistet.
Ich muss es auf den aktuellen Stand beruhen lassen weil ich nicht mehr rekonstruieren kann wie es wirklich war
EDIT: das war sicher der Fehler!
Hab nicht versucht es zu rekonstruieren sondern diese Statements neu programmiert und jetzt stimmt es.
Danke euch, manchmal ist man alleine blind! _________________ Grüße
kilix |
|
Nach oben |
|
 |
|