Beiträge von Oscar

  • PNG in Listview

    Nun, wir haben keinen Zugriff auf Deine Datenbank, was das Ganze schwer nachvollziehbar macht.

    Aber bei Deinem Script fällt mir auf, dass Du in Zeile 30-33 "_GUICtrlListView_AddColumn" benutzt.

    Zum hinzufügen von Items benutzt man aber "_GUICtrlListView_AddItem" für das Item und "_GUICtrlListView_AddSubItem" für die SubItems.

    Außerdem solltest Du mal checken, ob die Pfade in $array auch korrekt sind (mit "_ArrayDisplay" beispielsweise).

  • merkwürdiges Verhalten bei DirMove

    Zitat von AspirinJunkie

    Edit: Wurde schon vor 8 Jahren berichtet aber als kein Bug abgetan (für mich nicht nachvollziehbar):

    Das kann ich auch nicht nachvollziehen!

    Vor allem, weil DirCopy diesen "Fehler" eben nicht macht.

    Ein weiterer Workaround wäre demnach: erst DirCopy und dann (bei erfolgreichen DirCopy) DirRemove.

    So, wie er momentan funktioniert, kann man von DirMove jedenfalls nur abraten.

  • merkwürdiges Verhalten bei DirMove

    Ah, es gibt einen WinAPI-Befehl der das macht, was ich mir vorstelle: _WinAPI_ShellFileOperation

    Und zwar so:

    AutoIt
    #include <WinAPIShellEx.au3>
$sSource = 'd:\Quelle'
$sDest = 'd:\Ziel'
_WinAPI_ShellFileOperation($sSource, $sDest, $FO_MOVE, $FOF_NOCONFIRMATION)

    Und mit "0" statt $FOF_NOCONFIRMATION kommt sogar noch eine Nachfrage, was geschehen soll.

    Ich habe also einen Workaround gefunden, aber das Verhalten von DirMove empfinde ich trotzdem als fehlerhaft.

  • merkwürdiges Verhalten bei DirMove

    Zitat von Musashi

    - Existiert hingegen $sDestinationDir (auch wenn leer), dann schlägt DirMove fehl (hier greift $FC_NOOVERWRITE).

    Achso!

    Ich muss als Ziel dann "D:\Ziel\Quelle" angeben. Ok, so funktioniert es zumindest mit $FC_NOOVERWRITE.

    Aber mit $FC_OVERWRITE werden nicht die Dateien in "D:\Ziel\Quelle" überschrieben, sondern es wird noch ein Unterverzeichnis erstellt und die Dateien dort hinein verschoben.

    Ich müsste also vorher ein evtl. existierendes Verzeichnis löschen.

  • merkwürdiges Verhalten bei DirMove

    Ich bin gerade auf ein merkwürdiges Verhalten von DirMove gestossen.

    Vorab die Testumgebung:

    Quellverzeichnis ist: $sSource = 'd:\Quelle'

    Zielverzeichnis ist: $sDest = 'd:\Ziel'

    Punkt 1: Führe ich nun ein DirMove($sSource, $sDest, 0) aus, also mit 0 = $FC_NOOVERWRITE, dann passiert gar nichts! Das Verzeichnis "Quelle" wird nicht verschoben, obwohl es nicht im Zielverzeichnis vorhanden ist.

    Ein DirMove($sSource, $sDest, 1) mit 1 = $FC_OVERWRITE, verschiebt das Verzeichnis hingegen in das Zielverzeichnis.

    Punkt 2: Aber, und jetzt wird es total kurios, führe ich DirMove($sSource, $sDest, 1) nochmal aus (also mit bereits existierendem Verzeichnis "Quelle" im Zielverzeichnis, so werden nicht die Dateien in "D:\Ziel\Quelle" überschrieben, sondern das Quelle-Verzeichnis wird nach "D:\Ziel\Quelle" verschoben. Es existiert dann "D:\Ziel\Quelle\Quelle" mit den Dateien aus "D:\Quelle".

    Ok, in der Hilfe zu DIrMove steht Punkt 2 so geschrieben: "If the destination already exists and the overwrite flag is specified then the source directory will be moved inside the destination."

    Aber das ist doch völlig absurd! Ich will doch lediglich, dass das Verzeichnis "Quelle" nach "Ziel" verschoben wird und dabei ein bereits vorhandenes "Quelle" überschrieben wird.

    Muss ich dazu wirklich alle Dateien einzeln verschieben (mit FileMove)?

    Oder habe ich etwas übersehen?

  • GUICtrlClock

    Zitat von AutoMit

    Das wird wahrscheinlich zu aufwendig sein, da dann auch die Fenstergröße neu berechnet werden muss ...

    Ja, dazu müsste ich die meisten Funktionen umschreiben.

    Als Workaround kannst Du an den Anfang Deines Scripts Global Const $aHide[4] = [4, 5, 8, 9] setzen.

    Und dann nach dem aktualisieren der Uhrzeit (mit _SetClockTime) fügst Du eine Schleife ein:

    AutoIt
    For $iIndex In $aHide
   GUICtrlSetState($aClock3[$iIndex], $GUI_HIDE)
Next

    So werden die Sekunden und die beiden Punkte versteckt.

  • WIMS (where is my space)

    autoiter: Danke, für die Tests unter Win10. Ich werde die beiden Werte (3 und 1400) mal mit in das Script aufnehmen, auch wenn ich nicht verstehe, warum diese Meldungen auftreten.

    Eventuell gibt es unter Win10 noch irgendwelche Eigenarten beim Dateisystem ähnlich den REPARSE_POINTs.

  • WIMS (where is my space)

    Zitat von bazii

    Edit: Diesen Fehler bekomme ich auch bei anderen Laufwerken wenn ich größere Verzeichnisse auswähle.

    Das Skript stürzt bei mir unkompiliert oder kompiliert ab,[...]

    Das ist kein Absturz!

    Das hatte ich eingebaut, um zu sehen, welche @extended-Fehlermeldungen auftauchen können.

    Aber bei @extended = 0 (siehe Dein Screenshot) darf die MsgBox eigentlich gar nicht kommen. :/

    Es muss aber etwas mit Win10 zu tun haben, weil bei mir (mit Win7) kann ich auch C: problemlos scannen (auch mit 0MB, das dauert dann zwar lange, aber ohne Fehlermeldung).

  • Prüfen, ob eine Datei geöffnet ist

    Ach, in Deiner Ini stehen ja bloß die Verzeichnisse!

    Dann musst Du doch mit _FileListToArray (den Parameter $bReturnPath auf TRUE setzen) erst die Dateien einlesen (dort kannst Du dann Filter setzen).

    Anschließend das Array mit den Dateien durchgehen. So hast Du für _WinAPI_FileInUse den kompletten Dateinamen (mit Pfad).

  • WIMS (where is my space)

    WIMS ist ein Tool, um auf der Festplatte nach großen Dateien Ausschau zu halten.

    Man muss einen Suchpfad vorgeben, kann zusätzlich festlegen, ob der Suchpfad rekursiv (inkl. Unterverzeichnissen) durchsucht wird und ob auch versteckte Dateien/Ordner mit einbezogen werden sollen.

    Am wichtigsten ist aber die Vorgabe ab welcher Dateigröße die Dateien in der Liste aufgenommen werden sollen. Wählt man die Dateigröße zu klein, werden sehr viele Dateien gefunden. Das geht schnell in die Hunderttausende und dann dauert das Sortieren und das Einfügen in das Listview relativ lange.

    Bei der Vorgabe (nur Dateien größer 10 MB) ist das Tool aber recht schnell. Wenn man versehentlich eine zu kleine Dateigröße gewählt hat und es einem zu lange dauert, kann man die Suche auch mit {ESC} abbrechen.

    Ist die Liste erstmal erstellt, kann man mit einem Doppelklick auf einen Eintrag die entsprechende Datei starten (wird per ShellExecute aufgerufen).

    Außerdem gibt es noch ein Kontextmenü, in dem man Dateien löschen oder an einen anderen Ort verschieben kann.

    Es ist schon interessant, was da zum Vorschein kommt. Ich konnte schon so einige Dateien entsorgen, die sich in den Untiefen meiner Platte versteckten. :)

    Screenshot:

    WIMS_Screenshot.png

    Edit 08.10.2017: Kleines Update, damit das Script auch unter Win10 fehlerlos läuft. Danke, autoiter!

  • PNG in Listview

    Bitnugger: Deine Funktion kann man noch etwas erweitern, um auch Bilder aus dem Speicher laden zu können:

    Als Beispiel (mit PNG im Speicher) würde das dann so aussehen:

    Spoiler anzeigen

  • Prüfen, ob eine Datei geöffnet ist

    Zitat von Mikki

    FileMove($INI_READ_Section_1 & "\*.xlsx", $INI_READ_Section_2)

    Ich sehe gerade $INI_READ_SECTION_1 und [..]_2.

    IniReadSection liefert eigentlich ein 2D-Array zurück. Dann wäre Dein Script-Auszug falsch!

    Aber abgesehen davon, wenn Du die Pfade aus einer Inidatei liest, dann brauchst Du ja gar kein _FileListToArray.

    Die Dateinamen und Zielverzeichnisse liegen ja dann bereits vor.

    Also einfach nur die Dateinamen aus der Inidatei einzeln (in der oben angesprochenen Schleife) durchgehen.