Delphi-PRAXiS
Seite 1 von 3  1 23      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   SHFileoperatio-Ärger (https://www.delphipraxis.net/175843-shfileoperatio-aerger.html)

Mattze 23. Jul 2013 14:09

SHFileoperatio-Ärger
 
Hallo,

ich kriege es einfach nicht hin.
Früher (winXP) war SHFileOperation multithreaded. Heute nicht mehr (win7,8 32,64, pro).
Früher habe ich es aufgerufen und dann ging es in meinem Programm weiter. Kopiert wurde im Hintergrund. Ich konnte sogar das Copy nochmals anstoßen usw.
Das kriege ich jetzt nicht mehr hin. Der win Explorer tut es aber. Evtl. nutzt der aber auch IFileOperation. Nur, dieses Interface habe ich in D7 pro (SHLObj) noch nicht definiert (erst ab Delphi 2010).
Was tun?
Hat jemand einen Tipp für mich (außer einer neueren Delphi-Version!).
Wie kann ich das Copy threaded machen?

Gruß
Mattze

sx2008 23. Jul 2013 17:58

AW: SHFileoperatio-Ärger
 
Zitat:

Zitat von Mattze (Beitrag 1222391)
Früher (winXP) war SHFileOperation multithreaded

Kann ich mir nicht vorstellen.
1.) es gibt kein CopyAsynch-Flag oder vergleichbares Flag
2.) die Funktion SHFileOperation liefert einen einfachen Rückgabewert
Code:
Return value
Type: int
Returns zero if successful; otherwise nonzero.
Kein Hinweis darauf, dass die Funktion asynchon arbeiten könnte
3.) in der Struktur SHFILEOPSTRUCT gibt es das Bool-Flag fAnyOperationsAborted, das von SHFileOperation gesetzt wird.
Würde SHFileOperation sofort zurückkehren und intern Threads starten um die Operation zu bewerkstelligen, dann hätte niemand die Möglichkeit um festzustellen ob die Kopier-/Lösch- oder Move-Operation wirklich beendet ist.
Das Flag fAnyOperationsAborted wäre sinnlos, weil man nicht sicher feststellen kann ob der Wert gültig ist.

Mattze 23. Jul 2013 19:53

AW: SHFileoperatio-Ärger
 
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 24. Jul 2013 08:44

AW: SHFileoperatio-Ärger
 
Selber Kopieroperation als getrennten Thread abspalten?

Mattze 24. Jul 2013 08:58

AW: SHFileoperatio-Ärger
 
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 24. Jul 2013 09:46

AW: SHFileoperatio-Ärger
 
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 24. Jul 2013 10:25

AW: SHFileoperatio-Ärger
 
Zitat:

Zitat von Mattze (Beitrag 1222452)
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 24. Jul 2013 10:57

AW: SHFileoperatio-Ärger
 
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 24. Jul 2013 11:25

AW: SHFileoperatio-Ärger
 
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 24. Jul 2013 11:34

AW: SHFileoperatio-Ärger
 
Das geht!

Gruß
K-H


Alle Zeitangaben in WEZ +1. Es ist jetzt 19:46 Uhr.
Seite 1 von 3  1 23      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz