Hallo Liste, hallo Frank,
Du schriebst:
Unnötig zu erwähnen, dass Programme, die diese Typen benutzten, mit "langen Dateinamen" Probleme bekamen, als Windows sie endlich erlaubte (was zu Dos-Zeiten anscheinend unvorstellbar war -- wer hatte damals auch schon was von anderen Betriebssystemen gehört, die das vielleicht schon seit Jahrzehnten konnten, aber ich schweife ab ... ;-)
;-)
In dem speziellen Fall von 2. zumindestens denke ich, daß eine mögliche Fehlerquelle auszuschlossen wird, wenn ich z.B. mit ReadStr diese Variable wieder zu LongInt machen möchte.
Aber halt nur eine. Der String kann immer noch nicht-Ziffern enthalten,
Hier noch einmal: Wo sollen die herkommen, wenn der String so entsteht, daß er als Zahl in einer Datei abgelegt wird (wo diese natürlich als String "ihr Dasein fristet" (;-), um anschließend mit ReadLn als Zahl wieder eingelesen zu werden.
Also ich denke folgendermaßen: Wenn es in diesem Fall möglich wäre, daß dem String andere Zeichen als nur Ziffern durch irgendeinen mysteriösen Vorgang "untergeschoben" werden können, dann wäre bestimmt noch niemand zum Mond geflogen, weil man sich beim Rechner auf gar nichts mehr verlassen könnte.
Hingegen, wenn z.B. ein Programm eine Zahl einliest, die vom Benutzer eingegeben werden soll, dann verstehe ich den Sinn eines Fehlerabfangens, denn da kann ja versehentlich oder auch absichtlich alles mögliche eingegeben werden.
Aber im obigen Fall?
Verstehe das bitte nicht als Unwillen: Ich möchte es nur verstehen, sonst kann ich damit nicht wirklich etwas anfangen und sinnvoll arbeiten.
also besteht die Möglichkeit von Laufzeitfehlern immer noch. (Natürlich könnte man das vorher noch testen, aber dann ist es wiederum einfacher, "Val" oder so zu verwenden, das einem gleich sagt, ob die Umwandlung erfolgreich war.)
Wenn überhaupt, dann scheint das in meinem Fall das geeignete Mittel zum Fehlerabfangen sein.
Muß ich auch noch mal testen, habe ich nämlich noch nie benutzt.
Danke und Fröhliche Grüße Roland