kopieren von Dateien

[Manfred]

Hi,

ich möchte ganz gerne Dateien kopieren. Allerdings sollte das über Befehle im Programm geschehen. Ich würde allerdings ganz gerne einen Laufbalken, oder ähnliches dabei anzeigen. Gibt es da irgendeine Funktion aus dem OS, die man benutzen kann, oder wie könnte man sowas bauen? Unter Clipper habe ich das damals mit Fread() und Fwrite() gemacht, aber bevor ich jetzt anfange das umzustricken, wäre schon interessant ob es auch anders geht.

[Günter Beyes]

Hallo Manfred,

von Thomas Braun gibt es
http://www.software-braun.de/dl/ShFile.zip.

Das implementiert die API-Kopierfunktion mit dem "fliegenden Ordner".

Viele Grüße,
Günter

[Manfred]

Hi Günter,

danke für den Tipp, werde ich mir einmal ansehen.

[Rolf Ramacher]

Hi Manfred,


wie wäre es wenn du eine Batch-datei schreibst und diese dann im Programm aufrufst. Hat natürlich den Nachteil das die User diese Datei
verändern können.

[Manfred]

Hi Rolf,

es geht nicht darum das Kopieren anzuleieren. Da gibt es sicherlich eine Menge Möglichkeiten. Es geht mir um die optische Wahrnehmung des Kopiervorganges selbst, sprich den Balken.

[Tom]

Hallo, Manfred.

Klassisches Multithreading. Der eine (Haupt-)Thread kopiert, der andere zeigt einen Fortschrittsbalken an. Irgendeinen. Was genau willst Du wissen?

[Manfred]

Hi Tom,

ich versuche mich gerade damit sowas zu bauen. Ich wollte nur wissen, ob es sowas vielleicht irgendwie gibt, oder mit Bordmitteln zu machen wäre. Scheint nicht direkt der Fall zu sein. Ich werde aber erstmal ein wenig rumprobieren und dann evtl. hier nochmal ein paar Fragen posten.

Wobei sich allerdings jetzt schon die Frage stellt bei Deinem Vorschlag:

Wann müßte welcher Thread was machen und womit würde das Kopieren bewerkstelligt? Außer evtl. Fread() usw. wüßte ich jetzt nichts, was es zulassen würde zwischendurch den Laufbalken zu generieren.

[Markus Walter]

Hallo Manfred,

ich verwende weiterhin eine eigene Routine, die ich schon unter Clipper mit fread/fwrite erstellt habe. Damit lässt sich dann auch einfach ein Fortschrittsbalken implementieren.

Der Teufel steckt oft im Detail:
noch aus Clipper-Zeiten hatte ich einen relativ kleinen Puffer benutzt (10kb). Das war auch lange kein Problem, aber bei einem externen USB-DVD-RAM-Brenner war der Vorgang sehr langsam. Der gleiche Brenner eingebaut war schnell...
Deswegen steht der Puffer mittlerweile auf 1MB.

[Lewi]

Hallo Manfred,
Tom hat Dir mit dem Threadansatz einen Weg aufgezeigt. Low-Level Funktionen zum Kopieren brauchst nicht notwendiger Weise einzusetzen. In einem eigenen Thread könntest Du in Intervallen u.a. die jeweils aktuelle Dateigröße der Zieldatei abfragen. In Verbindung mit der bekannten Größe der Ausgangsdatei sollte sich somit auch über die Standard-Copy-Funktion eine Fortschrittsanzeige programmieren lassen.


Viele Grüße
Olaf

PS: Sind die Sektorengrößen zwischen Ausgangsdatenträger und Zieldatenträger unterschiedlich, kann es vorkommen, dass die Dateigrößen marginal differieren. Im Zuge der Anzeige kann dieses Problem vernachlässigt werden, allerdings sollte Dein Vergleichs-Algorithmus bezogen auf die Dateigröße das berücksichtigen.

[Manfred]

Hi Olaf,

das war doch mal wieder ein prima Tipp. Zu prüfen, wie groß die Zieldatei schon ist im Verhältnis zur Quelldatei. Daran habe ich jetzt überhaupt nicht gedacht.

[brandelh]

Hallo,

in Windows gibt es eigentlich keine genauen Fortschrittsanzeigen wie sie unter DOS damals programmiert wurden ( 5% der Datei kopiert, also 5% Balken ausfüllen ...) Die AVI Anzeige läuft endlos, die Anzeige der Restzeit schwankt stark etc. Dies liegt sicher auch daran, dass ein Multitasking Rechner gar nicht in der Lage ist abzuschätzen wie schnell er eine Datei kopieren kann, wo doch ein anderer Prozess plötzlich die Festplatte oder die CPU stark belasten kann.
Zudem sind alle solchen Anzeigen und Berechnungen ja auch recht Rechenintensiv.

Also könnte man es sich selbst ganz einfach machen:

einen Thread aufmachen, der z.B. copy file xxx to yyy startet und in einem anderen Thread einen Laufbalken oder sonst was erzeugen, das eine Änderung am Bildschirm vollbringt. Dieses müsste solange Laufen, bis eine Flag-Variable vom copy thread das Ende signalisiert bekommt.

Der oben angegebene Link benutzt - glaube ich mich errinnern zu können - halt das AVI Controll, das man auch vom Explorer her kennt.
Den Aufwand für das Erstellen eines solches AVI kann ich nicht beurteilen, aber eventuell findest du ja das Original-Windows-Explorer AVI ?

Da fällt mir gerade ein ... Alaska hat auch Beispiele dazu veröffentlicht:

\xppw32\source\samples\solution\progress

optisch nicht ganz ausgereift, aber du kannst es ja verbessern

[Lewi]

Hi Hubert,
wenn eine Restzeit errechnet werden soll, dann spielt sicherlich zum Zeitpunkt der Messung die aktuelle Ressourcenauslastung zur Abschätzung der Restzeit ein Rolle.

Bei einer Anzeige, die jeweils einen absoluten Wert anzeigt, wie beispielsweise "5% von 100%" oder "3122 KB von 54600 KB kopiert", dann sind Berücksichtigungen von Ressourceauslastungen obsolet.

Viele Grüße
Olaf

[Manfred]

Hi,

ein Laufbalken, der nur die Menge anzeigt ist vollkommen ausreichend. Es geht nur darum, dass der User nicht das Gefühl bei großen Dateien hat, es tut sich nichts mehr: Affengriff

[brandelh]

Hallo Lewi,

ich stimme dir völlig zu, wollte aber zum Ausdruck bringen, dass es

1. unter Windows viele 'Verlaufsanzeigen' gibt, die sehr ungenau oder endlos arbeiten.
2. sehr unschön ist, wenn man - wie der Explorer - Restzeiten anzeigt, die sich sehr schnell ändern und auch sehr ungenau sind. Dann lieber nichts anzeigen.
3. es wesentlich einfacher ist, die fertigen Befehle und ungenaue Kopierroutinen zu nutzen, als beides genau aufeinander abzustimmen.

Unter VO 1.1 hatte ich anfangs genauso Laufbalken z.B. bei Indexerzeugung wie unter Clipper. Bis ich mitbekommen habe, dass der Index doppelt so schnell ohne die Anzeigen aufgebaut wird und zudem die Indizierungzeiten immer kürzer wurden.

Eventuell reicht ja auch einfach eine Sanduhr als Mauscursor

[brandelh]

Hallo,

ich wußte ich hatte schon mal ein Beispiel mit dem Kopiervideo gesehen:

http://www.alaska-software.com/scripts/ ... IB_SECT=12

Dort unter BDVIDEO ...

Wenn es einfacher sein soll kann man auch einfach ein rotes Static immer breiter werden lassen und damit ein grünes überdecken ... oder umgekehrt.

[Jan]

Hallo Hubert,

auch wenn ich Dir teilweise recht geben muß: In sehr vielen Fällen ist Manfreds Einwand gerechtfertigt. Eine Sanduhr oder das Kopier-Video sind OK für Vorgänge bis ca. 10 Sekunden Dauer. Alles danach gibt den meisten Usern das Gefühl, das Teil hängt.

Ich habe unter Clipper auch mal einen Laufbalken für Kopiervorgänge geschrieben. Der auch relativ gleichmäßig ablief. Aber auch wenn das ungleichmäßig wäre: Der User hat doch wenigstens das Gefühl, es passiert etwas.

Natürlich muß man das ordentlich machen: Wenn der z. B. nur fortschreitet, wenn eine weitere Datei kopiert wurde, das Kopieren aber 2 Minuten braucht, dann denkt der unbedarfte User wieder mal an einen Hänger. Sehr schön finde ich den Fällen eine doppelte Anzeige: Gesamtverlauf und aktuelle Datei.

Ich habe das auch schon gemacht daß ich einfach untereinander weg geschrieben habe, was gerade passiert: Adressen sichern, Aufträge sichern, Orte sichern, ... Dateinamen sagen dem User nichts, aber die sprechenden begriffe sind OK, und er sieht, das da offensichtliches etwas sinnvolles oder sogar wichtiges passiert.

Lächerlich sind, da hast Du recht, Laufbalken, die nichts aussagen. Weil etwa die 100 % nie erreicht werden, oder aber massiv überschritten. Habe ich schon häufig (warum eigentlich gerade da?) unter Delphi-Programmen gesehen. Und auch ich habe es schon erlebt, daß die Fortschrittanzeige bzw. das Berechnen derselben so viel Resourcen geschluckt hat, daß man das lieber hätte sein lassen. In vielen Fällen muß man nicht alle 100stel Sekunde nachrechnen, wie gerade der Status ist, und dann die Anzeige entsprechend neu berechnen. Bei langwierigen zu beobachtenden Vorgängen reicht sicher eine Aktualisierung jede Sekunde oder noch seltener durchaus aus.

Jan

[Tom]

Wenn man Funktionen wie FileCopy() (XbTools) oder COPY FILE (X++) oder gar, Gott bewahre, irgendeine CMD-Funktion per Batch oder so benutzt, wird man wenig Informationen über den Verlauf erhalten. Wer Informationen über die Menge der kopierten Daten erhalten will, kann sich auch nicht auf FileSize() oder ähnliche verlassen, da solche Daten vom Caching abhängig sind, zudem setzt das Betriebssystem die Größe meistens erst am Ende eines Kopiervorganges. Es gibt also zwei Möglichkeiten:

a) FileCopy() oder COPY FILE benutzen. Vor dem Aufruf wird ein Thread gestartet, der einen (nicht proportionalen, also keine Prozentangabe!) Fortschrittsbalken oder irgendein anderes Gimmick anzeigt. Der Thread terminiert nach Abschluß der Funktion.

b) Auf die API-Funktion CopyFile() zugreifen. Die erlaubt die Installation einer Callback-Funktion, der auch die Menge der kopierten Daten übermittelt werden. Das ist etwas fummeliger, aber man lernt dabei.

[brandelh]

auch wenn ich Dir teilweise recht geben muß: In sehr vielen Fällen ist Manfreds Einwand gerechtfertigt. Eine Sanduhr oder das Kopier-Video sind OK für Vorgänge bis ca. 10 Sekunden Dauer. Alles danach gibt den meisten Usern das Gefühl, das Teil hängt.

ich denke ich habe mich missverständlich ausgedrückt.
Ich kann deinen Anmerkungen nämlich ohne Einschränkungen zustimmen.

Mein 1. Punkt mit den 'ungenauen Fortschrittsanzeigen' sollte eigentlich zum Ausdruck bringen, dass es OK ist, wenn man z.b. eine durchlaufenden Balken hat, der sich selbst löscht und von vorne anfängt (man sieht er arbeitet ...) oder aber einen Text (im MLE mach ich das gerne) der eine Art von Verlauf anzeigt. Oder eine sonstige Animation, die klar macht ich weiß zwar nicht wie lange noch, aber ich arbeite daran.
Denn das ist bei anderen Programmen und Windows selbst auch so.

Ich finde es auch schlecht, wenn mehr als 2 Sekunden der Bildschirm gar nichts anzeigt, außer bitte warten oder die Sanduhr ... allerdings habe ich auf aktuellen PCs kaum noch Situationen in denen die 2 Sekunden erreicht werden.

[Manfred]

b) Auf die API-Funktion CopyFile() zugreifen. Die erlaubt die Installation einer Callback-Funktion, der auch die Menge der kopierten Daten übermittelt werden. Das ist etwas fummeliger, aber man lernt dabei.

Das meinte ich ja. Irgendwas, was evtl. schon vorhanden ist. Wie kann ich darauf zugreifen, bzw. wie setzt man das ein? Ich habe NULL Ahnung von API Funktionen

[brandelh]

oder gar, Gott bewahre, irgendeine CMD-Funktion per Batch oder so benutzt

nun ja, Gott lasse ich aus dem Spiel, aber XCOPY nutze ich gerne wenn mehrere Dateien mit Pfaden oder Wildcards kopiert werden sollen.
RunShell() liefert die ErrorLevel zurück, somit kann man auch auf Fehler prüfen.

Bei dem oben angeführten Link von Thomas Braun (ShFile.zip. ) kann ich übrigens keine Animation finden. Ich dachte übrigens Xbase++ kann gar keine Call-Back nutzen ?

Die AVI Anzeige ist übrigens ein CommonControl vom Typ "SysAnimate32" der PowerBasic Quellcode ist aber nicht leicht zu übersetzen. Es wird ein 'CreateWindow "SysAnimate32"' erzeugt und dieses einem 'Custom Control' (benutzerdefiniertes Control) zugeordnet.

Ich bin mir nicht sicher, ob und wann ich das übersetzt bekomme, vielleicht steht dazu ja auch was im Alaska Forum, mal heute Abend nachsehen.

[Tom]

Hallo, Manfred.

Die API-Funktion heißt CopyFileEx() und liegt in der KERNEL32.DLL. Sie erlaubt die Installation einer Callback-Routine, die Informationen über den Verlauf erhält, und das wiederum bedeutet, daß Du mit dem BinaryAccessPackage (BAP) arbeiten mußt. Das ist nicht gerade trivial, vorsichtig ausgedrückt, aber ich könnte Dir in der kommenden Woche ein Beispiel bauen. Genaugenommen würdest Du das aber auch mit FRead() und FWrite() hinbekommen, wenn Du vorher die Dateigröße ermittelst und dann in Zehner-Chunks (FileSize()/10) liest und schreibst. Da könntest Du dann sogar ohne zusätzlichen Thread einfach eine Fortschrittsanzeige aktualisieren. Was sprach nochmal gegen diese Variante?

API-Funktionen findet man in verschiedenen DLLs im Windows-System(32)-Verzeichnis, und wenn man in den Visual-Basic-Foren stöbert, findet man auch viele Beispiele, die sich adaptieren lassen. Der Aufruf solcher Funktionen ist sehr einfach, schau Dir mal das Beispiel für die Ermittlung des Temp-Verzeichnisses in der Wissensbasis an. Oder die Nummer mit den transparenten Fenstern.

[Manfred]

Hi Tom,

Hallo, Manfred.

Die API-Funktion heißt CopyFileEx() und liegt in der KERNEL32.DLL. Sie erlaubt die Installation einer Callback-Routine, die Informationen über den Verlauf erhält, und das wiederum bedeutet, daß Du mit dem BinaryAccessPackage (BAP) arbeiten mußt. Das ist nicht gerade trivial, vorsichtig ausgedrückt, aber ich könnte Dir in der kommenden Woche ein Beispiel bauen.

Danke für die Mühe, aber ich wollte hier nicht zu viel Aufsehen erregen. Im Moment ist es noch an 2.Stelle der Priorität. Ich wollte nur die Fühler ausstrecken, ob irgendwas anderes möglich, oder ratsam wäre.

Genaugenommen würdest Du das aber auch mit FRead() und FWrite() hinbekommen, wenn Du vorher die Dateigröße ermittelst und dann in Zehner-Chunks (FileSize()/10) liest und schreibst. Da könntest Du dann sogar ohne zusätzlichen Thread einfach eine Fortschrittsanzeige aktualisieren. Was sprach nochmal gegen diese Variante?

So habe ich es ja bisher gelöst. Es spricht nichts dagegen, es sieht bloß nicht so schön aus, weil der Fortschrittsbalken mit Blockgrafik im Textmodus gemacht wird. Naja und da dachte ich halt......

[AUGE_OHR]

hi,

Unter Clipper habe ich das damals mit Fread() und Fwrite() gemacht,
aber bevor ich jetzt anfange das umzustricken, wäre schon interessant
ob es auch anders geht.

Warum nicht die Cl*pper Funktion behalten und mit Xbase++ "aufbohren" ?

Code: Alles auswählen

FUNCTION         FILECOPY(cSource, cTarget,oDlg)
LOCAL oProgress1 , nCopied := 0
LOCAL nError
LOCAL aPrgFiles := Directory(cSource)
LOCAL nMaxBar   := 0

   nMaxBar   :=  aPrgFiles[1][ F_SIZE ]

   oProgress1 := ProgressBar():new( oDlg:drawingarea,, {12,64}, {302,12},, .F. )
   oProgress1:type  := XBPSTATIC_TYPE_RECESSEDBOX

   oProgress1:Create()
   oProgress1:minimum := 1
   oProgress1:maximum := nMaxBar/BUFFER_SIZE
   oProgress1:color   := GRA_CLR_BLUE 

   nError := FCopy( cSource, cTarget, oProgress1 )
   IF nError = 0
      nCopied++
   ENDIF

   oProgress1:destroy()

RETURN nError

/*
   Copy files
*/

FUNCTION         FCopy( cSourceFile, cTargetFile, oProgress )
LOCAL nSource, nTarget, cBuffer, nBytes
LOCAL aTime, nReadSum := 0, nWrittenSum := 0
LOCAL nError := -1

   cBuffer := Space( BUFFER_SIZE )
   nBytes  := BUFFER_SIZE

   /*
      Open source and Target
   */
   IF ( nSource := FOpen( cSourceFile, FO_READ + FO_SHARED ) ) == -1
   ELSEIF ( nTarget := FCreate( cTargetFile, FC_NORMAL ) ) == -1
      FClose( nSource )
   ENDIF

   IF nSource != -1 .AND. nTarget != -1

      /*
         Copy as long as no error occurs
      */
      DO WHILE (nError := FError()) == 0 .AND. nBytes > 0
         nBytes      := FRead( nSource, @cBuffer, BUFFER_SIZE )
         nReadSum    += nBytes
         nWrittenSum += FWrite( nTarget, Left(cBuffer, nBytes) )
         IF oProgress # NIL
            oProgress:Increment()
         ENDIF
      ENDDO

      FClose( nSource )
      FClose( nTarget )

      IF nError = 0 .AND. nReadSum = nWrittenSum .AND. FEXISTS(cSourceFile) .AND. FEXISTS(cTargetFile)
         aTime := GetFileTime(cSourceFile)
         SetFileTime(cTargetFile, aTime)
      ENDIF

      IF oProgress # NIL
         oProgress:current := oProgress:maximum
      ENDIF
   ENDIF

RETURN nError

gruss by OHR
Jimmy

[brandelh]

Die API-Funktion heißt CopyFileEx() und liegt in der KERNEL32.DLL

@TOM,

lese ich das in der Win32API richtig, dass wie bei copy file ... to ... keine Wildcards erlaubt sind ?

@Manfred,

diese Funktion (ohne Call Back) ist recht einfach einzubauen, macht aber nichts anderes als copy file to aus Xbase++ (gut du hättest eine mögliche Fehlermeldung). Eine Call Back Routine ist schwierig - insoweit wäre mir Toms Beispiel auch recht - aber damit hast du noch keine Verlaufsanzeige. Diese könntest du manuell in die CallBackRoutine einbauen.

Mit deiner eigene FRead()/FWrite() Routine wäre es aber sicher einfacher und du könntest die API Aufrufe sparen. Allerdings würde ich nicht einfach 1/10 der Datei als Blockgröße wählen, sondern mit verschiedenen Werten experimentieren und die Beste fest einstellen. Vor 2 Jahren war das bei mir 4KByte, eventuell wären auf heutigen Rechnern mit mehr Hauptspeicher größere schneller, aber wenn die Blockgröße zu groß wird, wird es wieder langsamer.

[Tom]

Hallo, Hubert.

lese ich das in der Win32API richtig, dass wie bei copy file ... to ... keine Wildcards erlaubt sind ?

Ja und? aDir() erlaubt doch Wildcards.