Was muss ich tun, damit ich die Variable in meinem Beispiel nutzen kann, ohne dass ich die Zeile in der Funktion:
Speichere doch den Returnwert der Funktion in einem Array und verwende diese in _ArrayDisplay.
Ich glaub du stehst gerade nur ziemlich aufm Schlauch.
Wenn die Variable mit Return zurückgegeben wird, ist der Variableninhalt dann nicht automatisch über den Variablennamen abrufbar?
Nein, das würde zu so krassen Inkonsistenzen führen, davon wollen wir gar nicht erst anfangen.
PS: Ansonsten versuche ich mich später daran - ich weiß, Alpines wird sagen, das ist eine gute Übung.
Bin ich denn so berechenbar geworden?
Man muss das Rad ja nicht tausend mal neu erfinden, und wenn man sowas schon gemacht hat dann ist es nicht verwerflich schon eine fertige Lösung zu wollen.
Wenn es eine Wunschliste von Änderungen gäbe - was würden wir uns wünschen?
- Die Größe eines Arrays für interne und externe Funktionen im 1. Index komplett entfernen.
- Optionale Typensicherheit (auch wenn es eine Skriptsprache ist).
- Funktionen überarbeiten und für ein einheitliches Konzept sorgen, siehe GUICtrlSetState und GUISetState.
- Sichere Abfragen ob Makros gesetzt sind.
Das käme mir zumindest in den Sinn, gibt bestimmt noch dutzende mehr.
Eventuell wäre Parallelisierung noch eine Möglichkeit.
Da du keine JOINS in deinen Queries hast wird man da vermutlich nicht mehr viel machen können.
Ja, daran denkt man immer nicht
ExpandVarStrings wäre -vielleicht- sogar besser:
Opt("ExpandVarStrings", 1)
$sCommand = "g:\2018\ f:\sicherung\2018\ /ETA /MAXAGE:$von$ /MINAGE:$bis$"Du musst in den Parametern für ArrayRec $FLTAR_RECUR angeben, standardmäßig arbeitet sie nicht rekursiv was wieder einfach nur eine miserable Designentscheidung ist.
Na den String kannst du in einer MsgBox oder mit ConsoleWrite ausgeben und dann mal in die CMD kopieren und so ausführen, dann siehst du da was schiefgeht.
Bei meinen Versuchen hat Dircopy einen Ordner nicht mehr "angerührt" wenn dieser schon vorhanden war - also auch keine neuen Unterordner/Dateien dort hinein kopiert - oder hab ich da was übersehen?
Ne, die Dokumentation ist einfach miserabel für die Funktion.
Wenn du es in AutoIt implementieren willst könntest du _FileListToArrayRec nehmen und bei jeder Datei prüfen ob sie existiert.
RunWait(@ComSpec & " /c " & "robocopy.exe", "g:\2018\" & "f:\sicherung\2018\" & " /ETA /MAXAGE:" & $von & " /MINAGE:" & $bis)
Deine Parameter sind falsch, du lässt keine Leerzeichen zwischen deinen Pfadangaben.
Lass dir mal die Parameter für robocopy in der Konsole ausgeben und füge sie dann in die CMD ein und du siehst den Fehler.
1. Dircopy kann das aber nicht
$FC_NOOVERWRITE (0) = (default) do not overwrite existing files
Wieso sollte das nicht funktionieren?
wir ?
Ist leider seit 3.0 oder 3.2 (?) closed Source.
Man könnte einen eigenen Interpreter schreiben der autoitkompatibel wäre.
Erweitert wurde da NICHTS, jedenfalls aus meiner Sicht der Dinge.
- Added: More _GDIPlus_* functions (18).
Technisch gesehen ist das keine Erweiterung aber trotzdem nicht zu vernachlässigen.
Ich werde die Version erst aktualisieren wenn ich meinen Rechner neu aufsetzen muss oder wenn mir mal richtig langweilig ist.
Ansonsten sehe ich dafür keine Notwendigkeit, die 3.3.14.2 läuft ohne Probleme.
Gäbe es denn einen überzeugenden Grund, die 3.3.14.5 zu installieren ?
Erweiterter Funktionsumfang, Bugfixes und vervollständigte Dokumentation: https://www.autoitscript.com/autoit3/docs/history.htm
ich meine da in der 3.3.14.4 usw. doch viele Bugs drin waren war es ja besser diese auszulassen.
Deshalb frage ich ja, ob sich dies in der 3.3.14.5 gebessert hat.
Achso meinst du das!
Ja, die Bugs in den Versionen davor wurden ja gefixt (laut Changelog).
Aber da sind noch ein paar Ungereihmtheiten drinne (z.B. die Win-State Konstanten sind IMMER NOCH NICHT in der AutoItConstants.au3 vorhanden, die kommen erst mit der 3.3.15.0 rein)
aber im groben glaube ich, dass sie die 3.3.14.2 ablösen kann.
Ich weiß aber nicht inwiefern eine Neuinstallation die alten Konfigurationen und custom Calltips und Farbeinstellungen über den Haufen wirft.
Ich hab das ganze Zeugs von der BASS-DLL im Include Ordner und würde ungerne wieder alles reinkopieren und die user-Calltips einfügen etc.
Welche Bugs sind denn in der 3.3.14.5? Ich persönlich hab immer noch die 3.3.14.2 drauf.
Ja, das ist ziemlich bescheiden. Aber das ist ein Hochkomma - kein Apostroph.
Das geht zwar ziemlich OT aber das ist ein Apostroph, kein "Hochkomma" (höre das Wort zum ersten Mal, ist vielleicht ein Synonym).
Das was du als ’ gepostet hast ist ein "RIGHT SINGLE QUOTATION MARK" also einfache Gänsefüßchen,
und das ' ist ein Apostroph, schau selbst nach: http://www.babelstone.co.uk/Unicode/whatisit.html.
Schau mal in Zeile 9 und 10... wo kommt denn da das \m und das \a her?
Die sind von der Forensoftware. Der Syntaxhighlighter setzt komische Escapezeichen nach Strings die mit einem Apostroph geschrieben sind statt mit Gänsefüßchen.
Hier:
Local $sTest = @ScriptDir & '\String mit Apostroph'
Global $aTest = @WorkingDir & '\String mit Apostroph'
$sTest = @ScriptDir & "\String mit Gänsefüßchen"
$aTest = @WorkingDir & "\String mit Gänsefüßchen"$a = @ScriptDir & '\bla'
$b = 'bla' & 'blub'Wenn du nur auf den Punkt prüfen willst hättest du auch einen Einzeiler nehmen können Return Not StringInStr($sStr, ".").
Du solltest auch die UDF anhängen wenn du schon eine verwendest.
Du kannst das WinMgmt auch in AutoIt callen mit ObjGet.
Das Script liefert mir für Windows 7 Home Premium x64 zwar keine Infos aber andere Queries (z.B. welches Service Pack installiert ist) funktionieren.
Vielleicht klappts ja bei dir und Win10. Ob das #RequireAdmin notwendig ist weiß ich nicht.
#RequireAdmin
$oWinMgmts = ObjGet("winmgmts:{impersonationLevel=impersonate}!\\" & @ComputerName & "\root\cimv2")
$oQuery = $oWinMgmts.ExecQuery("SELECT * FROM Win32_WindowsProductActivation")
For $oObj In $oQuery
MsgBox(64, "Info", "ActivationRequired" & $oObj.ActivationRequired & @CRLF & _
"RemainingEvaluationPeriod: " & $oObj.RemainingEvaluationPeriod & @CRLF & _
"GracePeriod: " & $oObj.RemainingGracePeriod & @CRLF)
Next