SHFileoperatio-Ärger

[Mattze]

Hallo,

nun,darüber will ich nicht streiten. Es geht nicht darum!
Vielleicht war der Systemdialog zum Kopieren auch nur nicht modal und jetzt ist er es. (So was habe ich mal gelesen.)
Fakt ist, dass nach einem Aufruf von SHFileOperation sofort zum Hauptprogramm zurückgekehrt wurde und ich dort beliebig weiterarbeiten konnte. Und sei es, dass ich weitere SHFileOperation(s) angestoßen habe.
Das geht jetzt nicht mehr und das hätte ich gerne wieder. Es stört doch sehr, dass das Hauptprogramm steht, wenn man nur etwas kopiert, bis das Copy erledigt ist.
Irgendwelche Ideen?

Gruß
Mattze

[CCRDude]

Selber Kopieroperation als getrennten Thread abspalten?

[Mattze]

Hallo,

tschja, ganz so einfach ist das nicht wegen der "CopyThreadVerwaltung". Es können ja sehr viele sein...
Ich versuche mir gerade so was zu basteln.
Einen "CopyThread und "ThreadCopyManager", in dem sich jeder "CopyThread" mit seinem Handle verewigt - solange er aktiv ist.
Warum? Nur erst mal ein Problem: Wenn das Hauptprogramm geschlossen werden soll und noch kopiert wird, soll das natürlich nicht einfach abgebrochen werden.
Aber ich bin mir sicher, dass da noch weitere Probleme lauern...

Gruß
Mattze

[jaenicke]

Dieser "Kopiermanager" könnte dann auch gleich dafür sorgen, dass nicht mehrere Kopiervorgänge parallel laufen, sondern dass diese nacheinander abgearbeitet werden um das ganze zu beschleunigen. Dann reicht da auch ein Thread, der immer mit den Vorgängen gefüttert wird.

[CCRDude]

Zitat von Mattze:

Nur erst mal ein Problem: Wenn das Hauptprogramm geschlossen werden soll und noch kopiert wird, soll das natürlich nicht einfach abgebrochen werden.

Das gäb's aber immer

• Ohne Threads würde das Hauptfenster nicht reagieren, das verleitet Benutzer zum Abschießen...
• Bei jedem Thread, den Du implementierst, musst Du diese Situation berücksichtigen.

Als simplen Workaround (der aber nicht so schön wäre wie die von jaenicke genannte Queue) könntest Du ein Hilfsprozess beilegen, den Du für jeden Kopierjob startest. Der läuft weiter, parallel (weil eigener Prozess) und auch noch wenn das Hauptprogramm geschlossen wird.

[Mattze]

Hallo,

das nacheinander Abarbeiten wäre eine Idee.
Es gibt nämlich noch ein größeres Problem (für mich mit D7):
"Dynamische Variable"
Da man vorher ja nicht weiß, wie oft der User den Kopiervorgang (per Thread) anstößt, also nicht weiß, wie viele Threads gestartet werden, kann man die Threadvariable nicht "vordefinieren" (was auch aus Platz- und Performancegründen sicherlich nicht schön wäre).
Ich kenne aber keine Möglichkeit, Variable während der Laufzeit zu erzeugen. Gibt es da was und das ist mir nur entgangen?
Wenn ich das nacheinander mache, brauche ich aber nur eine Threadvariable.
Und wenn ich den Thread nur über seinen Handle (oder ThreadID) anspreche (per API), brauche ich auch nur eine Variable - nehme ich an. Deshalb auch der "CopyThreadManager". Der hält eine Liste mit den Threadhandlen vor.


Gruß
Mattze

[CCRDude]

Hmm... das Problem verstehe ich nicht ganz.

Delphi-Quellcode:

var a: array of TMyThread;
begin
   SetLength(a, 4);
end;

geht nicht unter D7? Ansonsten... TList, gibt es das schon unter D7? Mindestens eine TStringList gibt es da, mit Objekten an jeder Zeile, als unschönen Workaround, wobei ich glaube, dass es eigentlich auch die anderen Dinge (dynamische Arrays und TList) geben dürfte.

[p80286]

Das geht!

Gruß
K-H

[Mattze]

Hallo,

die Methode kenne ich natürlich auch.
Finde ich hier aber nicht so schön bzw. aufwendiger.
Z. Bsp. möchte ich gerne fertige Threads auch rauslöschen.
Bei solchen Arrays müsste ich da umspeichern usw.
Außerdem wäre da mehr Speicherplatz von Nöten, weil ich eben die ganze Klasse TMyThread im Array halte.
Wenn ich eine TList habe, in der ich die Handles der Threads ablege, ist das Rauslöschen, Thread finden... alles kein Problem!
Halte ich HIER für die günstigere Variante.

Gruß
Mattze

@K-H: Und wie? (Außer mit den dynamischen Arrays von oben.)