Beiträge von Micha_he

Kopier Dir doch die deutsche Hilfe der 3.3.8.1, in den AutoIt-Ordner und benenn die Hilfe der 3.3.10.2 vorher um.
Dann kannst Du weiterhin die deutsche nehmen und im Bedarfsfall auf die neue per Explorer zugreifen.
Obwohl eine englische Hilfe eigentlich lesbar und weitersgehend aussagekräftig sein sollte, wenn man programmieren will. Da behindern meistens sogar die eingedeutschen Begriffe mehr, wie sie helfen.

Micha

versuch mal:

RunWait("Robocopy " & $DirDoc & " " & $DirBackupDoc & ' /MIR /R:3 /W:1 /XD "'&$DirDoc &'Eigene Bilder" /XD "'&$DirDoc &'Eigene Musik" /XD "'&$DirDoc &'Eigene Videos" /LOG+:U:\BackupLog\%date%.txt /NP' , "" ,@SW_SHOW)

Edit:
Oder besser (nimmt h/m/s mit):

RunWait("Robocopy " & $DirDoc & " " & $DirBackupDoc & ' /MIR /R:3 /W:1 /XD "'&$DirDoc &'Eigene Bilder" /XD "'&$DirDoc &'Eigene Musik" /XD "'&$DirDoc &'Eigene Videos" /LOG+:U:\BackupLog\%date%%time:~0,2%%time:~3,2%%time:~6,2%.txt /NP' , "" ,@SW_SHOW)

Deine Robocopy-Version kennt den Parameter /XD ?

Dann kann es daran liegen, das Robocopy den Ordner samt Unterordnern immer vollständig liest. Unabhängig davon, ob der Teil Später auch kopiert werden soll. Und so wie es den Anschein hat, passen dort die Rechte nicht oder ein Programm hat Dateien im Zugriff.
Ich habe schon gesehen, das z.B. CorelDraw Unterverzeichnisse anlegt, wo nur der User Zugriff drauf hat. Läuft dann das Script unter einem, Backup-Admin, kommt es zu identischen Fehlern !

Ich verwende immer die Parameter '/R:0 /W:0', damit Scripte an solchen Datein nicht unnötig lange hängen bleiben.

Schau einfach mal unabhängig von den Fehlern im Log, ob der Ordner ohne den ausgeschlossenen Unterordner kopiert wurde. Robocopy sollte das Spiegeln trotz des Logfile-Eintrages, ja fertig durchführen.

... /XD "Ordner1" "Ordner2"

bzw.

... /XD "' & $DirDoc & '\Eigene Bilder"'

Global $DirPath = "U:"
Global $DirBackupDoc = $DirPath & "\Backup\Dokumente"
Global $DirDoc = @UserProfileDir & "\Documents"

[...]

RunWait(@ComSpec & " /c robocopy " & $DirDoc & " " & $DirBackupDoc & ' /MIR /R:3 /W:1 /LOG+:U:\BackupLog\Documents.txt /NP /XD "' & $DirDoc & '\Eigene Bilder"', "" ,@SW_SHOW)

Info: Ich habe mal die einzelnen \ in einfache Anführungszeichen geschrieben, damit das Forum diese richtig anzeigt !

Die Comspec-Geschichte kannst Du bei Robocopy auch weg lassen. Wenn Robocopy im ScriptDir liegt, einfach:

RunWait("Robocopy " & $DirDoc & " " & $DirBackupDoc & ' /MIR /R:3 /W:1 /LOG+:U:\BackupLog\Documents.txt /NP /XD "' & $DirDoc & '\Eigene Bilder"', "" ,@SW_SHOW)

Edit: Nochmal die Robocopy-Befehlszeile berichtigt. Ohne Gewähr !

Die Koordinaten des Notepad-Fensters hast Du ja bereits.

Im SplashTextOn() kann Du die Koordinaten im Parameter 5 & 6 direkt verwenden.

Für die MsgBox empfehle ich Dir die _MsgBoxExDe-UDF welche ich HIER bereits in meinem Verschlüsselungs-Tool 'AKrypto verwende. Bei dieser MsgBox kannst Du ebenfalls deine Koordinaten verwenden.

Na gut, dann wieß ich schon einmal das weder mein Editor spinnt, noch meine neue AutoIt V3.3.10.2 einen 'neuen' Bug aufweist.
Ist zwar nicht schön, aber da es mir auch erst heute auffiel, nicht so extrem wichtig.

Wenn ich ein Script wie z.B.

#RequireAdmin

Exit 1

mit AutoIt3.exe ausführen lasse, dabei egal ob über SciTE oder bei mir der RJ TextEd, dann erhalte ich immer einen Exitcode 0.
Wahrscheinlich der Exitcode für das "Elevate".
Entferne ich das 'RequireAdmin' erhalte ich den richtigen Wert.

Getestet habe ich das unter 3.3.6.1 und 3.3.10.2.

Ist das schon einmal jemandem aufgefallen. Kommt man an den richtigen Exitcode trotz Nutzung von RequireAdmin ?

ab 3.3.10.x z.B. so

#pragma compile(Console, true) ; Kompilieren mit 3.3.10.x als Consolen-Anwendung

consolewrite($cmdline[$cmdline[0]]) ; Ausgabe letzter Parameter an die Console

Warum nicht direkt in die 'pref.js'-Datei schreiben ?

Seit V3.3.10.2 kann man im Script die #pragma-Direktiven verwenden.

z.B.:

#pragma compile(FileVersion, 1.1.1.1, 1.1.100.100)

Funktioniert dann direkt mit der Aut2Exe.exe ohne Wrapper.

Ich glaube

If $Kennwort == "TC5s6t" Then

sollte funktionieren.

Neues Update V0.512 !

- Fehlerkorrektur: Bei der Anpassung an AutoIt V3.3.10.2 hatte sich in der verwendeten Funktion "_GUICtrlTreeView_SelectItem()" ein Fehler gezeigt, der das erweitern des TreeView-Wurzelordners beim Start verhinderte. Dieser wurde korrigiert.

Das hat nichts mit FileGetSize() zu tun, sondern mit Windows bzw. dessen FileSystem.

Einzige Lösung die mir z.Zt. einfällt wäre, ggf. in die jeweilige Unterverzeichnisse mit FileChangeDir(".\Unterverzeichnis") zu wechseln und dann die Datei mit FileGetSize() abzufragen. Ich gehe aber ohne es getestet zu haben davon aus, das auch dann eine Fehlermeldung erscheinen wird.

Trotzdem viel Spaß beim probieren.

Neue Version 0.511 im ersten Beitrag.

Änderungen:

• Anpassung an AutoIt V3.3.10.x vorgenommen, indem die Versionskontrolle auf _VersionCompare()
  der Misc.au3-UDF umgestellt wurde. (Danke Oscar, so etwas habe ich gesucht und nicht gefunden !)

Nutzt Du unter Umständen die aktuelle Beta-Version von AutoIt ?

Das Programm sollte unter der stable V3.3.8.1 ohne Probleme laufen.

Edit:
Habe gerade festgestellt, das hinter dem Stable-Download welcher mit "3.3.8.1" beschriftet ist, eine scheinbar neue stable 3.3.10.2 zur Installation bereit steht.
Mit dieser neuen 3.3.10.2 ist leider die Abfrage

If @AutoItVersion < "3.3.8.0" Then ...

wahr, obwohl eine Version 3.3.10.2 genutzt wird. Warum muss diese Unter-Unterversion nun 2stellig sein ?

Sollte mit

#RequireAdmin
RegWrite("HKEY_CLASSES_ROOT\.scr", "", "REG_SZ", "scrfile")

klappen. (siehe Hilfe zu RegWrite)

Dann verzichte doch komplett darauf !

Filelist --> Array
Array --> per 'Zufall' durchlaufen
Datei --> Binär einlesen
im Ziel --> neue Datei (gleicher Name) anlegen und Daten aus Puffer schreiben
fertig....

Zitat von De Rand Ere

Die Funktion FileSetTime() scheint aber sehr zeitaufwendig zu sein. Ablauf z.Z: OrgDatei ins Temp - hier erfolg das Setzten des Zeitstempels - dann Move auf microSd-Karte. Das Ganze dauert aber länger als die gesamte ID3TAG-Manipulation (mit Lesen und Schreiben).

Du brauchst doch kein 'TEMP'. Du kannst doch FileSetTime() auf die SDCard-Datei anwenden.

wobei ich hier noch eines anmerken möchte:

Die Kommandozeile (also auch in BAT- oder CMD-Dateien) kann keinen UNC-Pfad als aktuelles Verzeichnis!

Starte ich also per RUN/SHELLEXECUTE eine BAT/CMD-Datei mit einem WorkingDir, dann geht es in der Batch verloren.

Hier gibt es für BAT/CMD-Dateien folgenden Trick:

In der Batch einfach das Pfade mit %~dp0[unterverzeichnis\datei] angeben, wenn sie im, bzw. unter dem Verzeichnis der Batchdatei liegt.
(%~dp0 = Laufwerk+Pfad der gestarteten Batchdatei, inkl. abschließendem Backslash)

Beim Ausführen von EXE-Dateien aus UNC-Pfaden (mit Angabe von '@ScriptDir' als 'WorkingDir') haben wir dagegen auch keine Schwierigkeiten.

Ich dachte wir sprechen die ganze Zeit über die Unterschlüssel:

...\.au3

und je nach Konfiguration dieses Schlüssels (siehe unter Standard im Unterschlüssel '.au3')

noch der Unterschlüssel:

...\au3_auto_file (so heißt er glaube ich im Standard)

Das ganze jeweils in:

1. 'HKEY_CLASSES_USER\Software\Classes' für den User

und

2. 'HKEY_CLASSES_ROOT' für alle Nutzer des Rechners, wenn nicht unter 1. anders konfiguriert.

Und falls das nun immer noch unklar ist, erinnere ich hier nochmal an den Post #3 von Alina !