Ohne global in diesem Fall

Moin!

Da du leider kein Skript zum Spielen mitlieferst, kann man nur erahnen, wie dein Programm aufgebaut ist.
Ich vermute, du befindest in im "OnEvent-Modus" und hast auf globaler Ebene nur eine While/Wend Endlosschleife. Alle Aufgaben werden in Funktionen und somit auf lokaler Ebene abgearbeitet, wodurch der Wert einer Variablen nach Verlassen der Funktion (also des Gültigkeitsbereichs) verloren geht.
Um das zu verhindern, gibt es das Schlüsselwort Static.
Achtung! Die Funktion scheint in der AutoIt Version 3.3.8.1 Bugs zu haben, die aber in der neuesten Version gefixt sind. Siehe "Statische Variablen und AdlibRegister. Bug oder normales Verhalten?"
Eine hiermit deklarierte Variable behält zwar ihren Wert nach Verlassen des Gültigkeitsbereichs, ist aber dennoch nur innerhalb dessen sichtbar. Somit belegt eine solche Variable zwar Arbeitsspeicher, "ballert" aber nicht den Namensraum zu, wie du es formuliert hast.
In deinem speziellen Fall würde sich allerdings auch eine globale Variable anbieten, man muß ja nicht völlig drauf verzichten
Ansonsten könntest du auch überlegen, die Werte in einer Ini zu speichern, was den Vorteil hätte, dass diese auch nach Neustart des Programes verfügbar wären.

Sanfte Grüße

Denkbar wäre sowas:

Func _StringStore($sData = Default)
Local Static $sLocalData = Null
If $sData = Default Then Return $sLocalData
$sLocalData = $sData
EndFunc

ConsoleWrite(_StringStore() & @LF) ;Da noch kein Wert übergeben worden ist, handelt es sich um einen Null-String
_StringStore("Mein String!") ;Wir übergeben jetzt einen String...
ConsoleWrite(_StringStore() & @LF) ;... Und siehe da!
;Natürlich ist noch alles veränderbar
_StringStore("Hello, World!")
ConsoleWrite(_StringStore() & @LF)

Das könnte man mit einem Dictionary innerhalb der _StringStore-Funktionauch noch universeller halten... Ich poste nachher mal ein Beispiel.

Gruß

Edit: Sowas meinte ich:

chesstiger
Was soll das denn für eine Lösung sein?
Statt direkt globale Variablen hinzuschreiben verpackst du die nur in einen Wrapper.
Du hast zwar vermieden explizit eine globale Variable zu schreiben hast aber den selben Effekt - mit den selben Problemen.
Alle Codeteile greifen weiterhin auf die eine Variable über ihren Namen zu (die halt nur in der Funktion als Static Dictionary verpackt sind) und können Sie verändern wie sie wollen egal ob das Auswirkungen auf andere Teile haben könnte.

hausl78
Lass es global.
Besonders bei kleineren Ein-Mann-Skripten ist das Problem nicht gravierend.
Es bringt dir nichts deinen Code unleserlich und nicht wieder verwendbar zu machen in dem du krampfhaft versuchst eine globale Variable zu vermeiden.

In AutoIt gibt es prinzipiell nur zwei Definitionsbereiche - außerhalb von Funktionen (global) und innerhalb von Funktionen (lokal).
Wenn der Dateinamen nicht global sein soll darf er ergo nur für die Dauer der Ausführung einer Funktion gelten.
Da der Dateinamen aber länger gebraucht wird sollte er also außerhalb einer Funktion definiert sein - also global.

Wenn zu der Datei noch mehr Informationen kommen würden die du auch als Variable brauchst (z.B. letzter Zugriff usw.) dann könnte man es noch, um es ein bisschen aufzuräumen, als DllStruct verpacken.
Dann hat man eine Variable mit mehreren Informationen, also quasi eine Art Dateiobjekt.

Seh ich auch so. Ein kompletter Verzicht auf global deklarierte Variablen mag zwar technisch umsetzbar sein, aber das erhöht eher die Risiken die durch den Einsatz globaler Variablen entstehen würden.

Grundsätzlich ist es eher wichtig sich genau Gedanken über die Benennung und den Zweck der Variablen zu machen. Braucht man eine Variable nur in einer Funktion ist das Thema klar, lokale Variable und gut. Wird sie nur in wenigen ausgewählten Funktionen benötigt sollte man sofern der Aufwand dafür nicht zu groß ist ebenfalls lokale Variablen verwenden die jeweils weitergereicht werden. Gerade in Bezug auf GUI Elemente ist das aber in der Regel nicht praktikabel, da du so ggf. eine große Menge an Parametern weiterreichen musst. Eine Lösung wäre hier dann der Einsatz von Arrays, das würde die Übergabe vereinfachen, dafür aber die Lesbarkeit des Codes erschweren. Bei solchen Sammelarrays sollte also am besten eine gute Dokumentation im Quellcode in jeder Funktion die darauf zugreift vorliegen. Wenn die Variable hingegen in sehr vielen oder allen Funktionen benötigt wird ist es per Definition eben eine globale Variable. Hier ist dann höchste Vorsicht geboten, da je nach Programmgröße eben schwer nachvollziehbar ist wer berechtigter oder ggf. auch unberechtigter Weise, also versehentlich den Inhalt der Variable geändert hat.

Am allerwichtigsten ist aber nicht die Frage "global ja oder nein?", sondern "deklariert ja oder nein?". Eine einzige Variable die als lokale gedacht war aber nicht deklariert wurde kann mit einer gleichnamigen globalen kolidieren. Daher sollte man sich zum einen niemals auf das "Dim" Statement verlassen und natürlich auch wirklich jede Variable explizit local oder global deklarieren.

Hilfreich ist hier auch der Einsatz von

AutoItSetOption("MustDeclareVars", 1)

Wo ist das Problem diese Variable als lokale Variable zu nutzen und an deine andere Funktion weiterzureichen? Machbar ist es aufjedenfall, ob es sinnvoll ist ist ein anderes Thema, das hängt davon ab wo du diese überall sonst noch brauchst.

Zitat von hausl78

[autoit]

;...
;global $globFullFilePath = "" ; global, weiß nicht wie ich den sonst in btn_recheck_click() reinbekomme
;...
Func frmMain_load()
;...
local $globFullFilePath = "" ; global, weiß nicht wie ich den sonst in btn_recheck_click() reinbekomme
;...
; Event Listener
While 1
;...
Case $hBtnReCheck
$globFullFilePath = btn_recheck_click($globFullFilePath)
;...
WEnd
EndFunc

[/autoit] [autoit][/autoit] [autoit]

func btn_recheck_click($var)
;...
$var = "irgendwasanderes"
return $var
endfunc

[/autoit] [autoit][/autoit] [autoit][/autoit]

Alles anzeigen

Ist mir klar, dass das Unsinn ist. Das sollte nur die Umsetzung der genannten Idee zeigen.

Gruß