ReadFile(hFile,...
-
hallo,
ich lese ReadFile(hFile,data,maxLen,&dwRead,NULL);
jetzt möchte ich aber byteweise einlesen .. da ich den einleseprozess per progressbar anzeigen möchte.
ich nehme mal an das muss dann in eine schleife alla:maxLen=GetFileSize(hFile,NULL);
data=(LPSTR)GlobalAlloc(GPTR, maxLen+1)
for (long i=0;i<maxLen;i++)
{
ReadFile(hFile,data[i],i+1,&dwRead,NULL);
Progressbar1->Position=i; // hier würde ich i auf 1-100 umrechnen
}
data[maxLen]=0x00;ist das so richtig?
und ist das byteweise einlesen nicht herheblich langsamer als wenn ich es in einem rutsch einlese?kann mir einer eventuell ein beispiel nennen wie ich sehr schnell einlese, aber trotzdem den status in einer ProgressBar anzeigen lassen kann?
(ProgressBar anzeige mach ich in einem Thread .. möchte nur wissen wie das mit ReadFile ist)
-
1.) Wieso hast du bei ReadFile i+1 stehen? du wolltest doch eigentlich immer nur 1 Byte einlesen
2.) 1 Byte finde ich etwas schwachsinnig, da das zu schnell geht, als das du die Progressbar verfolgen könntest (und sich die Pos. wenn die Datei größer ist durch die Umrechnung meist eh nicht ändert)Also nimm lieber etwas größere Schritte (z.B. 1024 Byte). Möglich wäre auch, dass du z.B. dass du die Dateigröße durch die Breite der Progressbar teilst und so ermittelst, wieviele Daten eingelesen werden müssen, damit sich die Anzeige überhaupt ändert. (Auch hier eine Packet-Mindestgröße - z.B. 1024 Byte). Die Umrechnung musst du natürlich trotzdem machen, bzw. überlässt dies Windows (dem Control) indem du als max die Dateigröße setzt und dann einfach immer die schon gelesenen Bytes als Positionswert
-
tjor deshlab frag ich ja ^^
alleine wenn ich ReadFile(hFile,data**[0]**,.. geht es nicht mehr
kannst nen beispiel zeigen wie man byteweise einliesst .. den rest mit /100 und so bekomme ich dann bestimmt hin
wäre sehr dankbar
-
versuchs mal mit data+i
-
a) Für einzelbyte-Lesen müßtest du
ReadFile(hFile,data+i,1,&dwRead,NULL);
data+i == &(data[i]) : adresse wohin gelesen werden soll
1 : anzahl der zu lesenden Bytesb) Wie schon gesagt - größere Blöcke.
erstens ist ein üblicher Progressbar eh' nie größer als 200 pixel (und selbst wenn - mehr als 100 Schritte machen selten Sinn.
zweitens frißt der progresbar und die einzel-reads wahnsinnig performance.c) Ich würde für die Blöcke das größere von 1K bzw. Dateigröße/(100..200) nehmen. Wenn du von Festplatte liest, wird die Datei eh' in 4K-blöcken eingelagert und in dein Puffer kopiert - was hinreichend schnell geht. Falls Diskette / arschlahmens netzwerk in frage kommt, kannst du die kleinste Blockgröße ja senken.
d) Wenn dein Progress nicht grad in nem anderen Thread erzeugt wurde, mußt du das neuzeichnen eh erzwingen (UpdateWindow).
Ist auch ein hübsches Spiel - mal das ReadFile rausnehmen, und mal schaun wieviel Zeit du einfach mit dem neumalen verbringst.e) Wenn du wirklich gute Performance brauchst, kannst du auf NT-basierten Systemen asynchron enlesen. Geht auf 9x-Systemen leider nicht von Haus aus, nur mit eigenem Thread.
f) Wenn du schon an Progress denkst, dan möchte man das auch abbrechen können... da drängt sich ein separater Reader-Thread geradezu auf.
-
a) hatte ich schon :=) *aber thx*
b) ich teile maxLen /100 und lese dann die teile ein
c) die dateien sind meistends >100MB (nur spezielle)
d) progressbar ist in thread .. ohne readfile 0s
e) ---
f) das prog ist extrem winzig und ich sehe das nciht vor .. dann kann man auch closen, es macht nciht wirklich viel ^^
-
einlesen von 175MB in 16s ist das langsam?
-
einlesen von 175MB in 16s ist das langsam?
kommt drauf an
Noch 'n gedanke:
Mit einem Memory Mapped File kannst du dir evtl. das einlesen (und die Kopie im virtuellen Speicher) sparen - da kannst du direkt über den Cache Manager auf die Datei zugreifen. Macht wirklich Spaß...