Theoretisch sind so viele Stellen relevant wie Pixel am Schirm für den Fortschrittsbalken/Scrollleiste dargestellt werden, wird natürlich trotzdem < 10000 bleiben bei üblichen Auflösungen.
Aber das Problem ist auch die Rückkonvertierung, also aus der aktuellen Position der ScrollBar die Position innerhalb der Datei zu bestimmen. Ein Int64 kann nur näherungsweise in einem Double gespeichert werden. Da passiert es auch mal das hochgerundet wird und man dann nicht mehr in ein Int64 konvertieren kann, obwohl es gehen sollte. High(Int64) = 9223372036854775807 wird zu 9223372036854780000 wenn man es in ein Double konvertiert. Also größer als der größte Int64-Wert.
Delphi-Quellcode:
procedure FloatTests;
var
i, i2: Int64;
e: extended;
begin
i := High(Int64);
e := i;
assert(e <= i);
// wird nicht bemängelt obwohl eindeutig falsch unter x64
i2 := Trunc(e);
// erzeugt exception unter x64 (überlauf)
assert(i = i2);
// stimmt immer unter x86, egal welche Int64 man dem e zugewiesen hat
end;
Das könnte man vielleicht noch umgehen indem man zusichert dass der Double-Wert immer kleiner als der maximale Int64-Wert ist vor der Konvertierung.
Da Trunc und andere Rundungsmethoden aber alle Exceptions werfen, muss man also immer vorhersagen wann es (implizite) Rundungen geben könnte die den Wertebereich überschreiten. In diesem Fall wäre es problemlos bis High(Int64) - 512. 10-byte Extended hat das Problem nicht.
Also, so oder so, es sind deutlich mehr Prüfungen und Codereviews notwendig, da auch häufig mal implizit in Extended gerechnet wird in Delphi, wenn man keine expliziten Gleitkommatypen angibt. Also etwa sowas:
Delphi-Quellcode:
var
i: Integer;
begin
i := Round(i / 20);
end;