Definiere "klappt nicht".
Frage: Da die Variable ja bereits definiert ist, reicht doch auch
Local $yyy
$yyy = "zzz"Es klappt!
Habe ich etwas falsch gemacht oder wie könnte es man anders erreichen?
Wenn Du Assign zum zuweisen benutzt, dann musst Du Eval zum auslesen benutzen.
Alles andere würde gar keinen Sinn ergeben.
Aber vermutlich liegt hier eher ein XY-Problem vor?!
Wenn Du Assign zum zuweisen benutzt, dann musst Du Eval zum auslesen benutzen.
Alles andere würde gar keinen Sinn ergeben.
Das hätte ich nach Lesen der Doku auch erwartet. Ich habe aber vorher schon Folgendes probiert:
Assign("yyy", "zzz", 1)
$y = $yyy
MsgBox(0, "Test", "y" & @Tab & "yyy" & @LF & $y & @Tab & $yyy)Das hätte ich nach Lesen der Doku auch erwartet. Ich habe aber vorher schon Folgendes probiert:
Dein Beispiel ergibt bei mir:
warning: $yyy: possibly used before declaration und error: $yyy: undeclared global variable
Das funktioniert so also nicht!
Oscar : Der 3-Zeiler zeigt hier folgende MsgBox:
---------------------------
Test
---------------------------
y yyy
zzz zzz
---------------------------
OK
---------------------------Erst wenn ich Opt("MustDeclareVars", 1) hinzufüge, bekomme ich einen Fehler für die Variable $y.
Edit: Der lässt ich allerdings mit Local $y vermeiden.
Erst wenn ich Opt("MustDeclareVars", 1) hinzufüge, bekomme ich einen Fehler ...
Selbst wenn ich explizit Opt("MustDeclareVars", 0) (0 = Variable muss nicht deklariert werden(default)) setze :
Opt("MustDeclareVars", 0)
;Local $yyy
Assign("yyy", "zzz", 1)
$y = $yyy
MsgBox(0, "Test", "y" & @Tab & "yyy" & @LF & $y & @Tab & $yyy)bekomme ich die identische Warnungs-/Fehlermeldung wie Oscar .
Erst wenn ich Local $yyy vor Assign aktiviere klappt es (bei mir).
Moin, die Lösung:
Ich habe hier vor Kurzem das Standardpaket AutoIt 3.3.14.5 (32) installiert. Ich starte meine Skripte normalerweise über das enthaltene SciTE-Lite mit F5. Damit läuft das Skript ohne Fehlermeldung.
Wenn ich allerdings au3Check.exe mit dem Skript füttere, kommen die von Euch genannten Fehler.
Warum gibt es diesen Unterschied?
Ich starte meine Skripte normalerweise über das enthaltene SciTE-Lite mit F5. Damit läuft das Skript ohne Fehlermeldung.
Wenn ich allerdings au3Check.exe mit dem Skript füttere, kommen die von Euch genannten Fehler.
Ungeachtet dessen würde ich Dir wirklich empfehlen, die (aktuelle) Vollversion des SciTE-Editors für AutoIt herunterzuladen und zu installieren !
SciTE4AutoIt3.exe (Current Version) ==> https://www.autoitscript.com/site/autoit-sc…itor/downloads/
Warum gibt es diesen Unterschied?
Mit der Lite-Version von SciTE habe ich nie gearbeitet.
Ich könnte mir aber vorstellen, dass in der Vollversion von SciTE ein au3Check integriert ist 
.
Die normale Version macht vor dem Aufruf nicht erst einen Au3Check.
Dies und einige andere Funktionen machen SciTe4AutoIt zur empfehlenswerten Alternative.
Oder du nimmst ganz andere Editor - ich persönlich nutze VSC - aber es gibt noch zig andere Möglichkeiten.
Meine Frage bezog sich eigentlich darauf, warum au3check.exe einen Fehler meldet, den autoit3.exe nicht erkennt. 
Weil der "Fehler" kein Laufzeitfehler ist - der Code läuft ja problemlos.
Laufzeitfehler würden vom AutoIt-Interpreter geworfen - ein solcher tritt jedoch nicht auf, also gibt es nichts zu melden.
Au3Check hingegen prüft den Quellcode auf bestimmte Muster.
Z.B. ob vor der Benutzung einer Variable soetwas wie "Local $x = ..." stand.
Wenn nicht geht es davon aus, dass die Variable nicht existiert wenn sie aufgerufen wird und bringt den entsprechenden Fehler.
Im konkreten Fall ist Au3Check nicht in der Lage ein Assign als Variablendeklaration zu erkennen - was im Grunde ja falsch ist.
Diese Unzulänglichkeiten von AU3Check sind jedoch bekannt, weswegen man Krücken wie #forcedef hierfür eingebaut hat - z.B.:
Assign("yyy", "zzz", 1)
#forcedef $yyy
$y = $yyy
MsgBox(0, "Test", "y" & @Tab & "yyy" & @LF & $y & @Tab & $yyy)Dann meckert Au3Check auch nicht mehr (MustDeclareVars lässt sich davon aber nicht beeindrucken).
Es wäre durchaus möglich Au3Check beizubringen auch Assigns zum größten Teil mitzubehandeln.
Jedoch es stellt sich die Frage für einen konkreten Anwendungsfall für Assign.
Im Grunde lässt sich alles auch ohne dies lösen und die hässlichen Nebeneffekte davon bleiben auch aus.
Also kurz: Finger weg von Assign/Eval
Ok, danke für die Erklärung!
Ich arbeite mit AutoIt 3.3.8.1.
Warum ich von AutoIt 3.3.14.... nichts wissen möchte, erkennt ihr hier:
Jedoch es stellt sich die Frage für einen konkreten Anwendungsfall für Assign.
Dem kann ich nur zustimmen!
Ich programmiere seit 15 Jahren mit AutoIt, aber in all den Jahren habe ich nie einen konkreten Anwendungsfall für Assign/Eval gefunden.
Ich hatte für mich mal einen Fall konstruiert, wo man dem Anwender eines Taschenrechners die Möglichkeit gibt, Variablen zu erstellen mit denen er dann rechnen kann.
Aber letztendlich kann man auch das anders lösen. Wenn also irgendwann Assign/Eval wegfallen würden, würde ich das vermutlich gar nicht bemerken. 
Auf Assign und Eval basiert meine gesamte _netcode TCP UDF. Da in der UDF jeder socket seine eigenen optionen und daten bekommt und ich zu unerfahren mit objekten bin, fand ich das man mit mit Assign und Eval sehr einfach sehr schnell daten verändern und aufrufen kann und das von überall. Ist wie mit globalen variablen, nur das diese dynamisch sind. Vorsicht ist aber geboten, verändert man sie an der falschen stelle kracht es. Vielleicht gibt es auch bessere und schnelle wege, aber bis ich die gefunden habe mache ich es erstmal so.
Vielleicht gibt es auch bessere und schnelle wege
Ja: Assoziative Arrays wie das Scripting.Dictionary-Objekt oder der Datentyp Maps in den AutoIt-Betas.
Ja: Assoziative Arrays wie das Scripting.Dictionary-Objekt oder der Datentyp Maps in den AutoIt-Betas.
Das werde ich mir mal genauer ansehen, danke schön für den tipp 
