bin durch .NET ziemlich auf Übersichtlichkeit, Lesbarkeit und andere Clean Code Askpekte getrimmt,
Ja, das sind so Paradigmen, die oft als unverrückbar dargestellt werden (wie z. B. auch die 80-Zeichen Zeilenlänge in Python). Das wird dann einfach nicht mehr hinterfragt.
Leerzeilen zum Gruppieren von Blöcken sind OK. Wird es mehr, leidet aus meiner Sicht die Lesbarkeit deutlich.
Ist sicher immer Geschmacks- und Gewohnheitssache. 
Mit RegEnumKey kannst du Unterschlüssel auflisten. Dann versuchst du ob zu den Schlüsseln dein gesuchter Eintrag existiert. Findest du nicht, musst du diese Prozedur für jeden gefundenen Unterschlüssel wiederholen. Pack das in eine Funktion, die in einer Schleife aufgerufen wird.
Für VSCode Anwender ist das auf jeden Fall ein nützliches AddOn.
Für AutoIt bin ich aber wieder zu SciTE zurückgekehrt. Da kann ich nach meinem Geschmack viel intensiver dran schrauben. Und mit Lua ist das eine tolle Sache.
Ich verwende VSCode, wenn ich mit Nim programmiere.
weil mir "koda" das Menü ursprünglich erstellt hatte
Mal als Tipp: Fang gar nicht erst mit Koda an.
- Die Controlpositionen und -Größen sind mehr als idiotisch (wer setzt ein Ctrl an x=27 (wenn ncht gerade das ein Ergebnis zur gleichmäßigen Aufteilung ist). In der Regel verwendet man doch "glatte" Werte, damit man erforderliche Anpassungen auch schnell auf andere Ctrl umsetzen kann
- Die Variablennamen sind sinnfrei. $Label1 und $Button5 sind so aussagekräftig wie ein nasser Laubhaufen.
- Dadurch, dass du also hinterher erstmal sinnvolle Namen vergeben musst, hast du auch keinerlei Zeitersparnis. Wenn du ein paar mal GUI rein per Hand erstellt hast, bist du auch nicht langsamer als mit Koda.
Also ganz als Anfänger ist es sicher nicht schlecht eine Hilfe zu haben, aber wenn du dann weißt, wie es geht brauchst du die Krücke nicht mehr. 
Falls jemand weiß, woran das liegen könnte, wäre ich sehr dankbar über einen Hinweis.
Du musst natürlich in deiner GuiGetMsg-Schleife den erstellten ID auch Aktionen zuweisen. Dann funzt das tadellos. 
In AutoIt scheint es hierfür keine Lösung zu geben oder? Dass heisst GUI beenden und neu starten wäre angesagt?
Dein Aufbau ist einfach nicht optimal.
1. GUI erstellen - Label ohne Inhalt
2. Funktion erstellen, die Werte (Dienst) abfragt und Ergebnis dem Label zuweist (GUICtrlSetData)
3. Funktion aufrufen bei Anzeige GUI
4. Entweder ein durch User ausgelöster erneuter Funktionsaufruf (Button) oder
5. Pollen der Funktion im Hintergrund (AdlibRegister) - auf vernünftiges Intervall achten
NB
Dauernd motzt du, warum das nicht so einfach ist, wie du willst und in Batch oder Sontwas ist das doch so einfach...!
Wenn du AutoIt nutzen möchtest (niemand zwingt dich dazu), dann musst du dich auch auf die Sprache einlassen und dir zuallererst ein Grundwissen aneignen. Das wird dir mit jeder Spache so gehen.
Da du anscheinend von Batch kommst, solltest du dich zuallererst mit dem Konzept von Funktionen vertraut machen und die in deinem Hinterkopf schwirrende "GoTo-Anweisung" dahin werfen, wo sie hingehört: auf den Scheiterhaufen der unglücklichen Programmierung.
Das Ziel war doch ganz einfach, ich möchte in der GUI angezeigt bekommen, ob ein entsprechender Dienst läuft oder nicht, dachte das hätte ich erwähnt.
Hier mal eine UDF von mir, kannst du dazu nutzen (Sie ist noch unvollständig, aber GetInfo funzt):
Bsp.:
#include 'Service.au3'
$sService = 'wuauserv'
$sInfo = _Service_GetInfo($sService, '.', True)
ConsoleWrite("@@_Debug_line" & @TAB & @TAB & @ScriptLineNumber & " var: $sInfo --> " & $sInfo & @LF)@@_Debug_line 54 var: $sInfo --> Disabled, Stopped, OKGUICtrlCreateLabel("CUSTOMIZING" & _StringRepeat(" ", 185) & "Local DB-Server: " & $st, 10, 35, 980, 20)
Die Variable $st taucht hier erstmalig auf. Sie wurde vorher nicht deklariert, kein Wert zugewiesen. Somit erscheint die Fehlermeldung.
Es gibt doch eine MöglichKeit via RUN und Hide einen Batchbefehl im Hintergrund laufen zu lassen, kann man von diesem keine Variable an Autoit übergeben?
Direkter Austausch ist nicht ohne Weiteres machbar. Aber warum überhaupt Batch? Erledige doch alles in AutoIt.
PS: Wo istz die Syntaxeinstellung im Forum zu finden?
</> klicken zum Code einfügen, auf den Text "Quellcode" klicken und im Menü auswählen.
Und eine Bitte:
Wenn du Code postest, aktiviere in der Syntaxeinstellung "AutoIt". Die Autoerkennung funktioniert nicht und mit Syntaxhighlighting fallen Fehler viel schneller ins Auge.
Ich würde gerne dein Angebot wahrnehmen
Kannst du gern tun. Bitte auch noch ausreichend kommentieren, nicht immer wird klar, was du vorhast.
2. Wenn ich das Callback-Konstrukt nicht beende, würde es beim späteren Einscannen der Hardware-Parameter immer noch aktiv sein und den Ablauf kolossal stören.
Daher hatte ich die Kallback() geschrieben in der Hoffnung ich könne das Einlesen bei Bedarf neu starten...
Dazu fügt man in die _KeyProc an erster Stelle eine Bedingungsabfrage ein, also Prüfen ob ein Zustand/Variablenwert/Fenster-aktiv existiert, der die Weiterverarbeitung erlaubt.
If Not "BEDINGUNG" Then Return _WinAPI_CallNextHookEx($g_hHook, $nCode, $wParam, $lParam)
Noch ein gravierendes Problem:
$g_hStub_KeyProc = 0 in der Funktion "EvaluateKey".
Das darfst du unter keinen Umständen machen. Du sägst damit den Ast ab, auf dem du sitzt. denn du befindest dich zu diesem Zeitpunkt mitten in der Auswertung der Procedur. Danach hast du keinerlei definierten Programmzustand mehr. Somit verstehe ich auch deinen Wunsch nach Restart. - Das ist aber ausschließlich ein Rumdoktern am Symptom ohne die Ursache zu bekämpfen.
M.M.n ist das Problem die unsachgemäße Verwendung des Key-Hooks.
Das sind ja bisher alles nur Skript-Segmente. Wenn du magst, zeig mir mal dein gesamtes Skript und ich versuche das zu ordnen.
While-Schleife der GUI die Callback aufgerufen, damit ich wieder einlesen kann
Das ist sehr unglücklich gelöst.
Deine Funktion "Kallback()" ist ja nicht die Callback-Funktion, sondern initialisiert den Hook.
Die Initialisierung des Key-Hooks sollte einmalig am Skriptanfang erfolgen. Danach musst du dort nicht wieder ran.
Die registriert Callbackfunktion (_KeyProc) wird dann bei jedem Key-Event aufgerufen. In der Funktion wird nichts gespeichert. Es wird die Keyboard-Struct befüllt, die du anschliessend auswertest. Es existieren keine statischen Variablen, die einen Wert nach Verlassen der Funktion halten könnten.
EDIT:
Wo kommt eigentlich plötzlich die Variable "$sAusweisNr" her (EvaluateKey) - sie ist nirgendwo deklariert.
Auf die Deklaration Globaler Variablen hat water bereits hingewiesen - niemals! innerhalb von Funktionen!
Meine endgültige Lösung:
Ich habe den Schlüssel (mit allen Unterschlüsseln/Werten) jetzt von Hand im WOW6432Node erstellt. Den ganzen Zweig habe ich als *.reg exportiert. Hier wird dann auch der komplette Schlüsselname angezeigt.
Da ich weiß, dass die Ziel-PC alle 64-bit sind, kann ich die Installation mit Ausführen der *.reg - Datei durchführen. Da kann ich mir mein Skript sparen.
Damit besteht nur noch das Problem, daß der Eintrag nicht in Regedit angezeigt wird.
Er wird ja angezeigt, nur hatte ich dort (Zweig WOW6432Node) zuerst nicht gesucht, da ich diesen Zweig als 64-bit interpretiert hatte.
Das ist in etwa adäquat mit dem schönen Satz:
"Jetzt, wo ich weiß wie es geht, verstehe ich auch die Gebrauchsanleitung." 
Es geht hier nicht um das Abfangen von Fehlern sondern nur darum das Programm wieder auf Anfang zu setzen!
Ich würde das für diesen Fall so managen:
1. Deklaration aller erforderlichen Variablen
2. Erstellen einer Funktion _InitVars(), die allen Variablen die Startwerte zuweist
3. eine Arbeits-Funktionen erstellen, die in der (äußeren) Endlosschleife gestartet wird
4. in der Arbeitsfunktion eine Schleife, die bei Nichtauftreten von Fehlern kontinuierlich abgearbeitet wird - aber im Fehlerfall verlassen wird und die Variablen neu initialisiert
Hier ein Bsp.:
Global $gVar1, $gVar2, $gVar3
HotKeySet('!+n', '_Exit') ; Beenden mit "Alt+Shift+N"
_InitVars()
While 1
ConsoleWrite('Outer Loop' & @CRLF)
_MainFunc()
WEnd
Func _Exit()
Exit
EndFunc
Func _InitVars()
$gVar1 = 1
$gVar2 = 2
$gVar3 = 3
EndFunc
Func _MainFunc()
; Erreichen von Time >= 5 Sekunden wird als Fehler/Abruchbedingung interpretiert
Local $Timer = TimerInit()
ConsoleWrite('Start MainFunc, $gVar1/ $gVar2/ $gVar3 =' & $gVar1 & '/ ' & $gVar2 & '/ ' & $gVar3 & @CRLF)
While 1
$gVar1 += Random(1,10,1)
$gVar2 += Random(1,10,1)
$gVar3 += Random(1,10,1)
ConsoleWrite('Inner Loop, $gVar1/ $gVar2/ $gVar3 =' & $gVar1 & '/ ' & $gVar2 & '/ ' & $gVar3 & @CRLF)
Sleep(500)
If TimerDiff($Timer) >= 5000 Then ExitLoop
WEnd
Return _InitVars()
EndFuncDamit sich diese Einträge jedoch nicht mit denen der x64-Programme vermischen haben die in der Registry den extra Zweig WOW6432Node.
Beim Starten von x86-Programmen wird dieser lediglich auf HKLM\Software gemappt.
Ja, mit dem Mapping ist es dann auch klar.
Ich fühle mich gerade an ein Lied von Curd Jürgens erinnert (wird unter 50-Jährigen kaum bekannt sein):
Sechzig Jahre und kein bisschen weise,
...
...
Und doch sechzig Jahr' davon entfernt.
Falls ja dann liegt das Problem an einem Missverständnis.
Du schreibst, dass er deinen Eintrag in den x64-Zweig geschrieben hat (ich vermute du meinst WOW6432Node damit?).
Es ist jedoch genau andersherum:
HKLM\SOFTWARE ist der 64 Bit-Zweig
HKLM\SOFTWARE\WOW6432Node ist der 32 Bit-ZweigUnd mit der Info wird dann auch klar wie man die AutoIT-Hilfe interpretieren muss: HKLM64 gibt man an, wenn man von einem x86-Skript aus NICHT in WOW6432Node schreiben möchte.
OK, das bringt Klarheit. Dann habe ich das tatsächlich völlig entgegengesetzt interpretiert.
Danke für die Aufklärung. (Trotzdem mag ich die Registry nicht )
Nach dem HKLM noch die 64 einfühgen, dann sollte es gehen.
Ich will ja gerade keinen 64er Schlüssel einfügen.
Das war nur ein Test mit meinen Werten. Tatsächlich geht es um Einstellungen für die Borland Database Engine. Gibt es noch immer, wird zwar seit fast 20 Jahren nicht mehr weiterentwickelt, ist aber wie viel alte Software dadurch auch nicht verschlimmbessert worden.
Ich brauche dafür bestimmte Treiber und Spracheinstellungen, die in der Registry hinterlegt sein müssen. Vor 20 Jahren wusste noch niemand von kommendem Schlüssel "..Wow6432Node". Also möchte ich die Einträge so anlegen, wie sie vor 20 Jahren erwartet worden.
Da ich das auf mehreren PC ändern muss, hätte ich es gern automatisiert - das Skript dafür habe ich schon 2007 geschrieben. Habe es gerade syntaktisch überarbeitet und wollte testen, dabei ist mir das aufgefallen.
Notfalls halt doch Handarbeit.
OK, ich werde mich nie mit der Registry anfreunden.
Wenn ich im Editor den Schlüssel, wie eigentlich gewünscht, erstelle, ist er dort sichtbar - kann aber nicht gelesen werden! 
Dann frage ich mich aber: Wozu existieren dort Unmengen von Einträgen, wenn diese gar nicht gelesen werden können!!
Ich bin der festen Überzeugung, als die in Redmond sich den Reg-Scheiß ausgedacht haben, waren sie ständig bekifft. Nun merken sie, dass das Rotze ist und versuchen durch immer neue Verbiegungen das Teil am Laufen zu halten. Irgendwann haben wir 20 GB-Registrydaten und 10 GB OS.
