Filemove + Progressbar

  • Hallo,


    Warscheinlich stelle ich hier eine Frage die schon beantwortet wurde, leider habe ich nichts über die Suche gefunden.


    Eigentlich möchte ich beim FileMove eine Progressbar anzeigen lassen.


    Ich benutze folgenden Kode


    Code
    ;Move files if available
    Do
    FileMove($Tempfolder & "*.*", $importpath)
    Until FileFindFirstFile($Tempfolder & "*.*") = -1

    Ist es irgendwie möglich dort eine Progressbar einzufügen?
    Ich benutze diese Methode da der Filemove schneller ist als die Methode wo ich in einem Array die Dateien zuerst einlese und dann einzeln verschiebe. Warscheinlich wäre es bei dieser Methode einfacher eine Progressbar einzubauen.
    Möchte aber wissen ob es bei meiner aktuell benutzten Methode auch eine Möglichkeit gibt.


    Vielen dank.

  • Ja, du könntest eine ProgressBar mit dem Style Marquee:

    direkt vor dem Filemove starten und die ProgressBar danach mit GuiCtrDelete löschen.

  • Schau Dir mal diesen Beitrag an,
    Wartebildschirm mit Bewegung ?


    ich habe mich dann entschlossen, die " Selbstlaufenden" Warteschirme als Exe zu combilieren, diese mit run aufzurufen und entsprechend wieder zu beenden. FUnktioniert prima. Einmal starten, bewegte Animation läuft ab, mußt Dich um nix kümmern, wenn fertig beenden.



    Gruß


    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

  • Hallo,


    Vielen dank für eure Antworten.
    Ich habe es nun so gemacht dass ich eine separate exe erstellt habe die mir eine Progressbar anzeigt. Wollte das zwar verhindern, aber gut, kann damit leben :)


    Vielen dank nochmals.

  • Ich habe es nun so gemacht dass ich eine separate exe erstellt habe die mir eine Progressbar anzeigt. Wollte das zwar verhindern, aber gut, kann damit leben :)

    Hi laszia,
    sorry ich verstehe deine Meldung nicht ganz. Hast du den ersten Hinweis nicht verstanden? Hast du dich einfach für die hübschen Ladebildschirme von UEZ entschieden und wusstest sie nicht in deinen Code zu integrieren, oder warum musstest du auf eine externe Exe ausweichen?
    Eigentlich gibt es doch gar keinen Grund, warum du das unbedingt machen musst.
    Bsp:
    Local $idProgressbar = GUICtrlCreateProgress(10, 40, 200, 20, $PBS_MARQUEE)


    Das ist der erste Rat von autobert2 und von mir einfach bis auf den Style aus der Hilfe kopiert..

  • Ich hätte es vielleicht so gemacht:



    Ist nur schnell am Handy geschrieben aber wenn du nicht mit Unterordnern machst dann kannst du mit @extended von DirGetSize arbeiten, das returned nämlich auch die Dateianzahl eines Ordners und dann setzt du die einfach in Relation.
    Die Zahl die bei mir jetzt im ToolTip angezeigt wird kannst du ja dann selbst verständlich im Progress anzeigen. Ich konnte es jetzt leider nicht mehr testen aber ich denke es sollte funktionieren.


    LG Philipp

  • @autoiter
    was spricht dagegen das in eine eigene EXE auszulagern? Ich habe das an anderer Stelle auch so gemacht. Kam mir Ssinnvoll vor? Die "Bildchen" von UEZ habe ich auf meine Bedürfnisse angepasst, und compiliert. Nun rufe ich die einfach mit run auf. Brauche nicht jedesmal wenn ich das benötige, Source einzubinden. Über die Auslastung, zwei Programme gleichzeitig auszuführen, oder ob zwei "Abläufe paralell laufen" scheint mir nicht wirklich einen Unterschied zu machen.



    Gruß


    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

  • Hallo,


    Die optionen oben waren nicht genau das was ich wollte. Diese zeigen ja nur eine Progressbar dir hin und her läuft. Ich wollte eine Progressbar die mir zeigt wo ich gerade beim Move dran bin, also wieviele Dateien noch gemoved werden müssen.


    Mit einer separaten exe kann ich das Verzeichniss solange scannen bis keine Dateien mehr vorhanden sind, und dann halt auch eine Prgressbar anzeigen lassen.


    Was bei dieser Methode nicht sehr gut ist ist dass es als separates Fenster angezeigt wird und nicht wie ein Popup.


    Ganz am anfang hatte ich folgenden Kode



    AutoIt
    if IsArray($aFileList) Then
    if $aFileList[0] <> 0 Then
    for $k = 1 to $aFileList[0]
    FileMove($aFileList[$k], $importpath, $FC_OVERWRITE)
    next
    EndIf
    EndIf

    Dort hätte ich können die Progressbar einfügen. Nur dass dieser Kode langsam ist wenn man sehr viele Dateien verschieden muss.


    Wie gesagt, ich gebe micht momentan mit dem was ich gemacht habe zufrieden.

  • Doch hab ich gesehen :)
    Das problem ist dass der Status nicht geupdated wird, darum habe ich es in einer separaten exe laufen. Ich glaub dass das Skript solange beim move stehen bleibt bis alle Dateien verschiebt wurden und dann wieder weiterläuft.

  • Ich habe mal ein Beispiel für ein einziges Script was zeitgleich wie deins (ich habe Timer laufen lassen) kopiert und im selben Script einen Progress hat.



    bzw. hier nicht mehr ganz zeitgleich (etwa eine Sekunde) dafür etwas schöner




    Ich weiß du hast deine methode und die wird für dich passen aber ich dachte mir ich zeige noch eine andere möglichkeit das alles in ein script zu schalten.


    Und das mit FileFindFirstFile habe ich getestet: Du hast recht es dauert manchmal bis zu 4 mal so lange wie mit FileMove("*.*")



    *Edit:

    Zitat von Peter S. Taler

    An Rechenpower und Speicher mangelt es ja eh nicht.

    Bei dir vielleicht!


    Lg Phil

  • @'laszia - sorry das sehe ich gelassen. In Schönheit sterben bringt auch nichts. Sofern ich kein Verständnisproblem habe, liegt das Grundproblem ja bei Warteschleifen jeglicher Art, darin etwas zu tun - was autoit einerseits auslastet und den Bediener vor dem Schirm zum warten zwingt, und andererseits eine gediegene Info über die Wartezeit zu geben. Das kann autoIT nicht wirklich, z.B. bei runwait (soll ja ab und an vorkommen), bei Deinem move Problem dürfte es ähnlich aussehen. autoIT steckt im "Verarbeitungsprozeß" fest. Also eben die 2te exe.
    Ich kann mit der Lösung bequenm leben :) - keinen Knoten im Hirn. An Rechenpower und Speicher mangelt es ja eh nicht.




    Gruß


    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

  • @Phil_IT
    Habe mir das mal angeschaut und in einer separaten Scriptdatei ausprobiert. Muss mal schaun ob ich das so in mein script einbaue oder nicht :) Aber ist eigentlich das was ich machen wollte.


    Wie gesagt, habe das mit einer separaten exe erstellt und scheint für mich momentan ok zu sein...


    Vielen dank nochmals.

  • @Phil-IT
    mit Verlaub - es mangelt für dien "Kleinkram" bei niemanden an Rechenkapazität. 99% der Rechenpower steht ungenutzt in der Landschaft herum. So eine "Bildchen" exe läuft auch noch auf einem 10 Jahre altem Läppi :)


    Gruß


    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

  • @laszia: Es ging mir auch nicht darum, dass du es zwingend so machst wie ich sagte, nur wollte ich zeigen, dass es möglich ist
    @Peter: Das ist nicht wahr. Bsp VM würde reichen. 512 Arbeitsspeicher, ich glaube da ist die Leistung schnell am oberen Maximum.
    @BugFix: Du hast natürlich Recht, darüber habe ich gar nicht nachgedacht.

  • Sofern ich kein Verständnisproblem habe, liegt das Grundproblem ja bei Warteschleifen jeglicher Art, darin etwas zu tun - was autoit einerseits auslastet und den Bediener vor dem Schirm zum warten zwingt, und andererseits eine gediegene Info über die Wartezeit zu geben. Das kann autoIT nicht wirklich, z.B. bei runwait (soll ja ab und an vorkommen), bei Deinem move Problem dürfte es ähnlich aussehen. autoIT steckt im "Verarbeitungsprozeß" fest. Also eben die 2te exe.

    Obwohl Autoit kein Multithreading beherrscht, finde ich die Aussage verwegen.
    Bei den Programmen, die ich schon in AutoIt geschrieben gesehen habe, würde ich (gerade als Anfänger) erst einmal fragen, ob das stimmt, bevor ich das hier gewiss äußere.


    Hey @Phil-IT,
    laszia ist zufrieden. Nimm das nicht als Kritik deiner Arbeit. Deine Hilfe kommt vielleicht nicht immer so an, wie du es dir gewünscht hast. Ich hoffe aber, du hast vielleicht, etwas neues gelernt.
    Andere können sich dein Script ansehen und es nutzen und lernen.

  • Ich habe den Kode von Phil-IT natürlich getestet, auch um zu schauen wie und was es eigentlich macht. Und ich lerne immer wieder neue sachen, auch wenn ich diese vielleicht nicht oder nur teilweise in meinen Kode einfüge. Einen kleinen Teil von Phil-IT's Kode habe ich in meinen übernommen :)