Beiträge von BugFix

Zitat von JBO

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.

Zitat von JBO

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.

Zitat von casi4712

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.

Zitat von casi4712

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, OK

Zitat von casi4712

GUICtrlCreateLabel("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.

Zitat von casi4712

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.

Zitat von casi4712

PS: Wo istz die Syntaxeinstellung im Forum zu finden?

</> klicken zum Code einfügen, auf den Text "Quellcode" klicken und im Menü auswählen.

casi4712

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.

Zitat von hipfzwirgel

Ich würde gerne dein Angebot wahrnehmen

Kannst du gern tun. Bitte auch noch ausreichend kommentieren, nicht immer wird klar, was du vorhast.

Zitat von hipfzwirgel

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.

Zitat von hipfzwirgel

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.

Zitat von Tuxedo

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."

Zitat von hipfzwirgel

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()
EndFunc

Zitat von AspirinJunkie

Damit 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.

Zitat von AspirinJunkie

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-Zweig

Und 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 )

Zitat von sugus

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.

Zitat von sugus

Versuche mal ohne #RequireAdmin.

Dann kann ich nicht in die Registry schreiben. Es wird dann auch von RegWrite ein Fehler ausgegeben. (@error=1)

Im Normalfall vermeide ich die Arbeit mit der Registry, und wenn ich es dann doch mal nutze, eigentlich nur lesend. Nun wollte ich aber selbst einen Eintrag erstellen:

Folgendes Bsp.

#RequireAdmin

$iSucc = RegWrite('HKEY_LOCAL_MACHINE\SOFTWARE\BugFix', 'Test', 'REG_SZ', 'Mein-Wert')
MsgBox(0, 'RegWrite', "$iSucc --> " & $iSucc & @LF & "#Error:  " & @error)

Ich starte das Skript, die Benutzerkontensteuerung fragt an - ich bestätige und Regwrite wird laut Return-/Errorwert auch erfolgreich durchgeführt.

In der Registry ist aber keine Änderung sichtbar!

Aber ein RegRead('HKEY_LOCAL_MACHINE\SOFTWARE\BugFix', 'Test') zeigt, dass der Wert tatsächlich eingetragen wurde.

Weder ein Aktualisieren, noch ein Neustart des Reg-Editors veranlassen diesen, die Änderung anzuzeigen.

Ist das bei euch ebenso? Ich finde das schon recht verwirrend.

EDIT:

Auch nach einem PC-Neustart ist der Wert abfragbar, aber nicht im Reg-Editor sichtbar.

EDIT#2

Ich habe es gefunden. Obwohl ich explizit NICHT den 64-Bit Zweig angegeben habe, wird ungefragt dorthin geschrieben. Das ist natürlich Mist.

Wie kann ich dann definieren, dass nicht im 64-Bit Zweig geschrieben werden soll?

Laut Hilfe dürfte das nicht passieren:

When running on 64-bit Windows if you want to write a key or value specific to the 64-bit environment you have to suffix the HK... with 64 i.e. HKLM64.

Zitat von Oscar

Nö! Bei mir erscheint immer [Neuer Ordner] im Dialog.

OK, damit habe ich nicht gerechnet: Es gibt keinen Button, sondern oben in der Menüleiste steht (nahezu unsichtbar, da absolut flat) "Neuer Ordner". Da hätte ich die nächsten 20 Jahre nicht hingeschaut, schließlich hat das Ding da null Zusammenhang mit dem Dialog.

Am Besten noch einen Erkennung dafür einbauen, die einen roten Rahmen drum zeichnet.

Gut, nun bin ich schlauer - aber nicht einen Deut zufriedener.