Der Pfad bleibt aber gleich.
Darauf sollte man sich beim programmieren lieber nicht verlassen.
Nimm lieber:
Local $sString = StringTrimLeft($sLatestFile, StringInStr($sLatestFile , "\" , 0, -1))
MsgBox(64, "Info", $sString & " wurde entfernt!")Und wenn man faul ist, dann nimmt man einfach eine fertige Funktion: _WinAPI_PathStripPath 
Die GUIs solltest du ebenfalls überarbeiten, denn du rufst sie rekursiv auf. Das bedeutet, dass du von GUI1 zu GUI2 springst und dann von GUI2 GUI1 neu erstellst.
AlphavibeZ: Das ist genau so ein Beispiel, wie ich das hier angesprochen habe. Das missbrauchen von Funktionsaufrufen als Goto-Ersatz.
Wenn Du mehrere GUIs verwenden willst, erstelle beide am Anfang des Scripts und mache nur das gerade benötigte Fenster sichtbar (mit GuiSetState) und schalte das andere unsichtbar. So vermeidest Du das ständige löschen und wieder erstellen der GUIs.
Je nach Kenntnisstand ist es auch von Vorteil den OnEventMode zu benutzen.
Falls Du SciTE als Editor benutzt, rufe einfach Tidy (STRG & T) auf. Das formatiert den Code.
Was willst Du denn erreichen?
Soll die letzte Datei gelöscht werden, wenn die Messung nicht in Ordnung war oder wenn sie in Ordnung war?
Ja, es gab noch keine Labels (leider). Meine ersten Programmiererfahrungen stammen vom C64.
Basic nur mit Zeilennummern, Assembler im Maschinensprachemonitor (Sprünge durch abzählen der Bytes ermittelt 
).
So gesehen ist AutoIt da doch sehr komfortabel und dem fehlenden Goto weine ich keine Träne nach. Ich hab's in AutoIt nie gebraucht.
MsgBox(64 + 4, "Bewertung", "War die Messung i.O?")
Naja, Du fragst, ob die Messung in Ordnung war und antwortest wahrscheinlich mit "Ja".
Ja, setzt aber die Variable $bLoeschungabbruch = True und If Not $bLoeschungabbruch Then führt den Code aber nur bei False aus.
Somit passiert also nichts. 
Irgendwann hat man eben angefangen zwischen den Zeilen eben 100 oder 1000 Zeilen leergelassen, damit man immer Reserven hatte, falls man etwas hinzufügen oder wglöschen musste
Ohje, das sieht sehr nach C64-Basic aus.
Also wenn schon Goto, dann doch bitte Goto mit Label und nicht mit Zeilennummern.
Nur leider sehe ich den Zusammenhang zu unserer GOTO Diskussion nicht. Endlosschleifen brauchen - wie man sieht kein GOTO. Abstürze habe ich hier nicht
AspirinJunkie hat es schon vorweggenommen.
Das Problem bei dem Code ist, dass die Verwendung des Funktionsaufrufes als Goto-Ersatz eben nicht (dauerhaft) funktioniert.
Bei jedem Funktionsaufruf wird die Rücksprungadresse auf den Stack abgelegt und erst dann wird die Funktion aufgerufen. Erfolgt kein Rücksprung aus der Funktion füllt sich der Stack immer weiter, bis AutoIt schließlich einen Error auswirft (stack overflow).
Der zweite Fehler ist der, dass in Zeile 23 die Funktion "Eingabe" aufgerufen wird, aber danach ein ExitLoop oder Return fehlt, denn das Return beim Schliessen des Fenster springt halt zu der letzten Adresse auf dem Stack zurück und das ist an die Stelle nach Zeile 23 und somit hängt das Programm in der Endlosschleife fest.
Wenn ein Funktionsaufruf genau das gleiche wäre, wie ein Goto, dann würde das Script problemlos funktionieren.
Das ist aber nicht der Fall, eben weil man einen Funktionsaufruf auch wieder (mit Return) beenden muss, sodass man an die aufrufende Stelle zurückkehrt.
Sicher, mein obiges Beispiel ist die Extremversion.
Aber was ist hiermit:
#include <AutoItConstants.au3>
#include <ButtonConstants.au3>
#include <GUIConstantsEx.au3>
$iRek = 0
Eingabe()
Func Eingabe()
Local $hGui = GUICreate('Eingabe', 400, 90)
Local $idInput = GUICtrlCreateInput('', 10, 10, 380, 20)
Local $idNext = GUICtrlCreateButton('Nächste Eingabe', 130, 50, 120, 25, $BS_DEFPUSHBUTTON)
Local $idCancel = GUICtrlCreateButton('Abbruch', 260, 50, 120, 25)
GUISetState()
While True
Switch GUIGetMsg()
Case $GUI_EVENT_CLOSE, $idCancel
GUIDelete($hGui)
ExitLoop
Case $idNext
GUIDelete($hGui)
$iRek += 1
ToolTip($iRek, Default, Default, 'Test', $TIP_WARNINGICON)
Eingabe()
EndSwitch
WEnd
Return
EndFuncAuf den ersten Blick völlig in Ordnung, oder?
Findest Du die beiden Fehler?
Na gut, um Dir etwas mit auf den Weg zu geben:
Wenn Du "wild" von einer Funktion zur nächsten springst und von dort dann wieder zur nächsten und so weiter, dann wird Dir das Programm irgendwann abstürzen (Stichwort: begrenzte Rekursionstiefe).
Eine Funktion ist dazu da, aufgerufen zu werden, dann werden dort Berechnungen durchgeführt und sie muss mit Return (na gut, das ist in AutoIt optional) wieder verlassen werden. Jedenfalls muss die Funktion bis zum EndFunc kommen oder vorzeitig mit Return verlassen werden.
Anderenfalls erzeugst Du eine rekursive Funktion ohne Abbruchbedingung und die stürzt früher oder später ab (stack overflow).
Ein Beispiel dafür:
Test1()
Func Test1()
Test2()
EndFunc
Func Test2()
Test3()
EndFunc
Func Test3()
Test1()
EndFuncHier wird quasi nie das EndFunc "ausgeführt". Es wird vorher immer zur nächsten Funktion gesprungen.
In diesem Beispiel kann man das leicht überblicken, aber in richtigen Programmen sollte man einen Funktionsaufruf nicht als Goto-Ersatz missbrauchen, weil es genau zu obigen Verhalten führen kann.
Andererseits wird Code durch Springen zu (sprechenden) Funktionen auch nicht (unbedingt) lesbarer
Wenn Du Funktionen dazu verwendest, um das fehlende Goto auszugleichen, dann hast Du den Sinn von Funktionen noch nicht verstanden.
Wie stehst Du grundsätzlich zu der Idee, interessante Shoutbox-Diskussionen in den allgemein zugänglichen Forumsbereich zu überführen (z.B. wie hier als Zusammenfassung) ?
Wenn es sich um Themen handelt, die ausführlicher diskutiert werden können oder die insgesamt von Interesse sind oder sein können, warum nicht?
Da ist das Forum doch besser lesbar, als in der Shoutbox, wo die alten Beiträge dann oben verschwinden (nur noch im Archiv lesbar sind).
Wenn wir es mal auf AutoIt beschränken, dann ist GOTO überflüssig. In der ganzen Zeit, in der ich AutoIt bisher nutze (über 11 Jahre), habe ich das GOTO jedenfalls nie gebraucht.
In AutoIt haben wir drei Schleifen (For...Next, While....WEnd und Do...Until), wozu also ein Goto?
In Assembler ist das etwas anderes. Dort ist das JMP mitunter nicht verzichtbar. Das liegt aber auch daran, weil man es für Schleifen braucht.
Goto führt meistens, besonders bei Programmiereinsteigern, zu dem berühmt/berüchtigten Spaghetticode.
Natürlich kann man auch ohne Goto unleserlichen Code schreiben (das missbrauchen der Funktionen ist da sehr beliebt). Das weglassen von Goto macht einen nicht automatisch zum guten Programmierer.
Ich denke aber, dass man sich ohne Goto mehr Gedanken über den Programmablauf macht und vielleicht eher damit anfängt das Programm in kleine Teilprobleme aufzuteilen, die sich dann mit Funktionen abbilden lassen.
Weißt du Zufällig auch noch wo dran das liegen kann, dass bei mir diese Auswahlmöglichkeiten weg sind ? Habe AutoIT und SciTE schon neuinstalliert, aber bekomme das Menü noch nicht angezeigt.
Hmm...nein, wenn Du AutoIt und SciTE korrekt installiert hast, sollten die Auswahlmöglichkeiten eigentlich da sein. 
Ich plädiere ausdrücklich für die Verwendung von Konstanten anstelle von 'magic numbers'
Ja! Ich auch!
Ich muss mich zwar manchmal dazu zwingen (besonders bei StringSplit), aber es ist einfach lesbarer.
Ist es in der Vergangenheit schon häufiger vorgekommen, dass der Wert einer Konstante geändert wurde ?
Nein! Oder zumindest nicht, dass ich mich erinnern kann.
Von daher spricht das eher für die Benutzung der Werte, das gebe ich zu. 
Wenn man aber die bessere "Lesbarkeit" mit in die Waagschale wirft, dann doch eher die Konstanten.
Edit: Achso, ich wollte doch noch erwähnen, dass es eine neue Version gibt (Post#1).
Das liegt daran, das $LBS_SORT zum Defaultwert gehört.
Willst Du das nicht haben, musst Du halt nur BitOR($WS_BORDER, $WS_VSCROLL) als Style eintragen.
Etwas, was noch nicht erwähnt wurde, sind die "Script breakings changes" bei den genannten Konstanten.
Wenn beispielsweise die Konstante $GUI_EVENT_CLOSE mal irgendwann von dem Wert "-3" auf "-4" geändert wird, dann laufen sehr viele Scripte nicht mehr.
Die Verwendung der Konstanten hat also auch etwas mit der Lauffähigkeit des Scripts in der Zukunft zu tun, weshalb ich eigentlich immer die Konstanten (nicht die Werte) verwende.
Sehr verärgert bin ich darüber, wenn sich die Konstante selbst ändert. Siehe $ghGDIPDll in $__g_hGDIPDll, was zu vielen Problemen geführt hat.
Mein absoluter Favorit, das Umbenennen der Feldnamen der $TagBitmapInfo-Struct-KONSTANTEN
Hmm..das wird aber schwierig zu automatisieren.
Man müsste ja erstmal rausfinden, ob es sich bei der Strukturvariablen um eine $tagBITMAPINFO-Struct handelt und wenn die Deklaration in einer Includedatei stattfindet, wird es richtig eklig.
Und dann ist $tagBITMAPINFO ja auch noch unterteilt. Sie besteht ja zum Teil aus $tagBITMAPINFOHEADER (die Felder dieser Konstante müsste man auch korrigieren).
Da habe ich gerade keinen Lösungsansatz.
