Beiträge von misterspeed

Wie wäre es wenn du einen Beispielcode schreibst der das Problem veranschaulicht? Die zwei Zeilen da oben sind jedenfalls unbrauchbar um das ganze zu testen und ich bin zu Faul mir die restliche GUI selbst zu schreiben...

Zitat von Chulio

Ka was genau du meinst, weil...

3.) rechtsklick ausführen (x86) -> "AutoIt v3 Script funktioniert nicht mehr...Programm schliessen"
in SciTE -> "AutoIt v3 Script funktioniert nicht mehr...Programm schliessen"

rechtsklick ausführen (x64) ->

Status:
Es konnte keine Übereinstimmung ermittelt werden!

Wenn du nur ein klein wenig nachdenkst und mal einen Blick auf den Code wirfst den ich dir gegeben habe bzw. die Hilfe zu den von mir verwendeten Befehlen nachschlägst sollte dir klar werden, dass du die Debug Meldung, welche ich eingebaut habe nur in der Scite console sehen kannst. Das Ausführen per Rechtsklick auf die "au3" wird dich als nicht weiter bringen wenn es darum geht den Fehler zu finden. Du musst das Script also in Scite ausführen. Dabei musst du selbstverständlich darauf achten, dass du das Script in 64bit ausführst wenn du eine 64bit DLL verwendest bzw. eben als 32bit Version wenn du eine 32bit DLL verwendest (ansonsten Absturz...).

Das erzwingt man in dem man eine der folgenden Zeilen an den Scriptanfang setzt

#AutoIt3Wrapper_UseX64=N ; 32bit
#AutoIt3Wrapper_UseX64=Y ; 64bit

Wenn in der console keine Meldung erscheint wird wohl in der Tat nichts gefunden, wenn meine Debug Meldung erscheint, dann solltest du anhand des Fehlercodes des DLL calls den Fehler eingrenzen können.

Verdammt!

Hier eine Fassung, die sowohl für DOS commands, als auch normale Programmaufrufe mit und ohne Leerzeichen im Pfad funktionieren sollte:

EDIT:

Andy: Backslash bekommste angezeigt wenn du auf

'\'

ausweichst

Der Foren bzw. BB-Code Bug sollte trotzdem behoben werden, nervt irgendwie...

Der Code von PuReIroNie ist auch falsch. Schau dir doch einfach das Beispiel in der Hilfe zu

stdoutread

an:

; Demonstriert StdoutRead()
#include <Constants.au3>

Local $foo = Run(@ComSpec & " /c dir foo.bar", @SystemDir, @SW_HIDE, $STDERR_CHILD + $STDOUT_CHILD)
Local $line
While 1
$line = StdoutRead($foo)
If @error Then ExitLoop
MsgBox(0, "STDOUT gelesen:", $line)
WEnd

While 1
$line = StderrRead($foo)
If @error Then ExitLoop
MsgBox(0, "STDERR gelesen:", $line)
WEnd

MsgBox(0, "Debug", "Wie aufregend...")

Das Beispiel ist zugegebenermaßen nicht optimal, dein Fehler liegt vermutlich auch an der fehlerhaften Bildung des Befehlsstrings für run().

Du schreibst nämlich:

Run("C:\Program Files\RevoUninstaller\RevoCmd.exe" /m keepass* ... Parameter)

Was schonmal einen Syntaxfehler werfen dürfte, da du die Parameter nicht in Anführungszeichen einschließt.

Richtig wäre eher so:

Run("C:\Program Files\RevoUninstaller\RevoCmd.exe /m keepass")

Damit der stdout überhaupt gelesen werden kann muss wie im Hilfebeispiel noch das Flag für $STDOUT_CHILD im run() Aufruf untergebracht werden.

Hier das überarbeitete Beispiel auf deinen Fall angepasst:

#include <Constants.au3>

$sProgram = 'C:\Program Files\RevoUninstaller\RevoCmd.exe'
$sParam = '/m keepass'

$sOut = getCmdOut($sProgram & " " & $sParam)

ConsoleWrite($sOut & @CRLF)

Func getCmdOut($sExecute)
Local $pid = Run(@ComSpec & " /c " & '"' & $sExecute & '"', "", @SW_HIDE, $STDOUT_CHILD)
Local $sReturn

While 1
$sReturn &= StdoutRead($pid)
If @error Then ExitLoop
WEnd

Return $sReturn
EndFunc

EDIT:

Tja da war Andy flotter, dafür hab ich ne schöne Funktion draus gemacht.

Naja ein erster Schritt zum erfolgreichen Debugging wäre es für jeden Befehl den Rückgabewert und den @error Wert in die scite console ausgeben zu lassen. Diese Ergebnisse kannst du dann nutzen und in der UDF nachsehen was sie bedeuten. Soweit ich das gesehen habe sind die möglichen Fehlerrückgaben in den Funktionsköpfen benannt/dokumentiert.

Du hast leider trotz deines ewig langen Postings nichts zur eigentlichen Frage beigetragen. Was soll überhaupt automatisiert werden? Ohne diese Rückmeldung deinerseits kann man dir auch keine Alternativen vorschlagen.

Nun zum fehlerhaften Error Handling in der imagesearch.au3:

Ersetze diesen Code ab Zeile 43 in der imagesearch.au3

; If error exit
if $result[0]="0" then return 0

mit diesem Code

; If error exit
If @error <> 0 Then
ConsoleWrite("Fehler bei DLL Call in Imagesearch.au3 --> Errorcode: " & @error & @CRLF)
Return 0
Else
if $result[0]="0" then return 0
EndIf

Anschließende Vergleiche den Fehlerrückgabewert in der Scite console mit denen die in der Hilfe zur Funktion

dllcall()

aufgelistet werden:

Rückgabewert
Erfolg: 	@error = 0.
Fehler: 	setzt @error
@error: 1 Die Dll-Datei kann nicht verwendet werden,
	2 unbekannter Rückgabewert "return type",
	3 Funktion "function" wurde in der DLL-Datei nicht gefunden.
	4 Falsche Anzahl von Parametern.
	5 Falscher Parameter.
siehe Bemerkungen.

Anhand des genauen Fehlers kannst du vielleicht auch herausfinden warum die imagesearch.au3 bei dir scheitert.

EDIT:

Ein Blick auf den DLL Call der da scheitert sollte btw auch erklären warum er scheitert:

$result = DllCall("C:\ImageSearchDLL.dll","str","ImageSearch","int",$x1,"int",$y1,"int",$right,"int",$bottom,"ptr",$findImage,"ptr",$HBMP)

Na fällt jemandem was auf? Die DLL muss direkt auf C:\ liegen. Ein weiteres Zeichen für die unglaublich schlechte Programmierfähigkeit des Autors der UDF. Der DLL Pfad sollte nie hardcodet vorliegen, sondern per Variablenübergabe an die Funktion realisiert werden, oder wenn schon hardcodet dann zumindestens das @scriptdir.

Zitat von sklaim

Kann als [gelöst] markiert werden

Richtig, aber nicht von mir und auch von sonst niemandem, sondern von dir selbst. Einfach das erste Posting editieren und das Thread Präfix auf "Gelöst" ändern.

Zitat von Chulio

Zum einen sollte man denke ich nicht immer gleich aufgeben, wenn etwas nicht funktioniert...nur so meine Meinung und zum anderen sollte man eigentlich erwarten, das wenn jemand einem rät andere Wege zu beschreiten, die einen ebenso gut zum Ziel führen könnten, die selben dann auch mal zu nennen. Abgesehen davon gibt es immer andere Wege...das hätte ich mir auch schon vor dem Beitrag denken können.

Zum einen erwartest du scheinbar von uns, dass wir uns mit deinem Problem beschäftigen, die Frage ist also wer hier "immer gleich aufgibt". Warum sollten wir uns mit etwas beschäftigen, dass folgende Punkte erfüllt:

1. Unzuverlässig
2. Ineffektiv
3. Ganz offensichtlich ist die von dir genutzte UDF fehlerhaft bzw. macht kein gescheites Error Handling (der Absturz passiert innerhalb der UDF Funktion, außer du hast Code unterschlagen)
4. Du postest noch nicht einmal den Link zur UDF. Sollen wir die selbst suchen? Woher sollen wir wissen ob du die aktuellste Version verwendest wenn wir nicht einmal wissen wo du diese her hast?

Alleine Punkt 1 und 2 sprechen für Alternative Wege, Punkt 3 spricht ebenfalls gegen die Nutzung. Punkt 4 ist dein Verschulden und erschwert die Fehlersuche.

Nun zu deinem Vorwurf, dass wir die Alternativen nennen sollten, wenn es denn welche gibt. Hier bleibt anzumerken, dass man nur dann konkrete Alternativen nennen kann wenn man die Aufgabe kennt. Auch hier bist du uns eine Antwort schuldig, denn ich sehe nirgendwo auch nur einen Satz von dir in dem du dein vorhaben bzw. das Ziel des Vorhabens beschreibst.

Also vielleicht erstmal den Fehler am eigenen Verhalten suchen bevor du anderen den Vorwurf machst nicht besonders hilfreich zu sein.

Zitat von Chulio

Und vor allem gibt es auch andere wege als AutoIt.

Dann hast du ja eigentlich kein Problem? Davon ab ist die Nutzung einer DLL (was diese UDF ja tut) ohnehin kein Einsatz von nativem Autoit. Du könntest die DLL auch in vielen anderen Sprachen ansprechen.

Zitat von Chulio

Wie wäre es mal abwechselungsweise mit einem Post, der als Hilfestellung zu betrachten ist? Mein ich nicht böse, aber ich suche hier nach einer Lösung!

Meine ich auch nicht böse, aber wie oben erwähnt ist der erste Schritt zu brauchbarer Hilfe eine brauchbare Fragestellung und das Bereitstellen aller relevanten Ziele / Informationen / Links.

Ahja und am besten mal hier lesen, alles andere macht keinen Sinn wenn schon tausend API's zur Verfügung stehen sollte man diese auch nutzen:

https://blockchain.info/api

Für den Kurs braucht man die IE Funktionen nicht, das ginge auch so:

#include <string.au3>

$site = "http://markets.blockchain.info/markets/mtgox/EUR"
$source = BinaryToString(inetread($site,16+1))

$aKurs = _StringBetween($source,"<span id='last_price'>","</span>")

If $aKurs <> 0 Then
ConsoleWrite("Der aktuelle Kurs lautet: " & $aKurs[0] & @CRLF)
Else
MsgBox(0,"Fehler","Kurs String wurde nicht gefunden")
EndIf

$hwin = WinGetHandle("windows", "Adresse: C:\windows")
$iItem = ControlListView ( $hwin, "", "[CLASS:DirectUIHWND; INSTANCE:3]", "FindItem", "HelpPane.exe")

ConsoleWrite($hwin & @CRLF)
ConsoleWrite($iItem & @CRLF)

Prinzipiell so. Allerdings funktioniert der Code so nicht mit dem Windows Explorer unter Windows 7. Liegt sehr wahrscheinlich daran, dass dort kein Standardlistview mehr verwendet wird oder ich mit au3info nicht an das richtige Hanlde des Listviews rangekommen bin.
Für ein eigenes oder Standard Listview sollte der Code nach Anpassung des Fensterhandles und der Control ID aber funktionieren.

Andere Frage... wozu braucht man Zugriff auf den Windows Explorer auf diese weise?

Das Problem ist wie schon erwähnt wurde, dass sowohl msgbox() als auch sleep() (Script oben...) blockierende Funktionen sind. Außerdem hast du das Problem, dass Autoit kein Multithreading unterstützt, d.h. einzelne Funktionen oder Befehle können nicht paralell, sondern nur nacheinander ausgeführt werden. Echte paralelle Ausführung ist in Autoit nur durch separate Prozesse machbar.

Du könntest dein Script also z.B. teilen:

gui.exe (nur für die Anzeige und zum Start der Unterprogramme da)
worker.exe (führt deine zeitintensive Aktion durch und kommuniziert das Ergebnis an die GUI, falls notwendig)

Die GUI arbeitet so unabhängig vom Rest und bleibt reaktionsfähig. Es ist außerdem möglich mehrere worker zu starten, welche dann alle paralell arbeiten.

Eine andere Lösung wäre, dass zeitintensive Funktionen nebenher und regelmässig guigetmsg oder traygetmsg überprüfen (z.B. als Teil der Rechenschleife), allerdings werden die hinterlegten anderen GUI Funktionen trotzdem nicht paralell sondern bestenfalls verschachtelt abwechselnd ausgeführt. Das funktioniert außerdem nur dann wenn auf blockierende Funktionen wie sleep oder msgbox verzichtet wird. Um eine laufende Funktion abbrechen zu können wäre das jedenfalls eine gangbare Lösung.

Naja nicht sonderlich überraschend.

1. Wenn nichts angeklickt wird returned guigetmsg() immer 0
2. Deine Funktion _GetFilesFolder_Rekursiv returned ein Array mit Dateipfaden

Was passiert in deinem Code Abschnitt?

If $nMsg = $MenuSoundsItemSounds[$GetFolder[$i]][$GetFiles[$v]] Then

$GetFolder[$i] = Ein Verzeichnis, z.B. "C:\test\"
$GetFiles[$v] = Eine Datei des Verzeichnisses, z.B. "test.wav"

3. Beides sind Strings, also für Autoit gleichbedeutend mit einer 0.

Welchen Index von $MenuSoundsItemSounds sprichst du folglich immer an?

If $nMsg = $MenuSoundsItemSounds[0][0] Then

Wenn nun der Inhalt des Arrays $MenuSoundsItemSounds an diesem Index einer 0 entspricht (Leer, String oder tatsächlich eine 0) ist die IF-Bedingung immer dann erfüllt wenn nichts angeklickt wurde. Somit ist sie permanent erfüllt außer du klickst wild rum.

Das Ergebnis ist also so gut wie immer eine msgbox mit diesem Inhalt:

MsgBox (0, "", $GetFiles[$v])

Warum ist $MenuSoundsItemSounds[0][0] in deinem Fall immer eine 0 ? Weil du das Array erst ab [1][1] mit MenuItem IDs befüllst. Ändert aber nichts daran, dass du vermutlich diesen Vergleich machen wolltest:

If $nMsg = $MenuSoundsItemSounds[$i][$v] Then

Dann deaktivere mal deinen Virenscanner oder verzichte auf die UPX Kompression beim compilen.

Zitat von BugFix

Also ich sehe den Button.

Du bist auch Moderator und darfst auf geschlossene Threads antworten. Der Rest von uns darf dort leider nichts mehr posten

Also walte deines Amtes und öffne den Thread wieder

Die Funktion gibt nun ein 2D-Array mit allen gewünschten Daten zurück. Ich war außerdem mal so frei und habe alle Variablen lokal deklariert und einige andere Kleinigkeiten was die Reihenfolge und Übersicht anbelangt geändert.

Zitat von sklaim

Wie kann ich das umsetzten, das man selbst im Programm andere Programme hinzufügen kann, ohne extra so eine Datei anlegen zu müssen?

Naja irgendwo musst du diese Infos ja speichern, wenn sie beim nächsten Programmstart noch vorhanden sein sollen. Es liegt also nahe dafür eine ini Datei zu verwenden. Alternativ könnte man diese Dinge auch in der Registry speichern, was ich persönlich für unschöner halte, da die Daten so nicht mehr protabel und leicht editierbar sind. Ich sehe jedenfalls kein Argument gegen ein ini Datei solange die Daten nicht versteckt werden sollen, aber selbst das geht wunderbar mit einer ini Datei und den crypt Funktionen.

Die ini aus dem Programm heraus zu erstellen ist ebenfalls kein Problem, falls das die eigentliche Frage war:

• Du brauchst einen Button "Neues Programm hinzufügen"
• Dieser Button fragt bei Klick z.B. per [autoit]inputbox()[/autoit] oder über ein separates Fenster mit Inputfeldern nach dem $Name, dem $Pfad und den $Parametern
• Alle drei Informationen nutzt du dann mit
  [autoit]
  iniwrite("deine.ini",$Name,"setup",$Pfad)
  iniwrite("deine.ini",$Name,"parameter",$Parameter)
  [/autoit]
• Fertig, deine ini sollte nun einen neuen Programm Eintrag haben
• Anschließend solltest du den Inhalt des Dropdowns neu einlesen, damit das Programm sofort zur Auswahl verfügbar ist (siehe unten)

Zitat von sklaim

Und wie kriege ich es hin, das ich bei der Combo keine Einträge eingebe sondern ein Array, wobei jedes Feld für einen Eintrag steht?

Indem du einfach deine ini einließt und das Dropdownmenü mit diesen Informationen fütterst

$Combo1 = GUICtrlCreateCombo("", 8, 8, 185, 25, BitOR($CBS_DROPDOWNLIST,$CBS_AUTOHSCROLL,$CBS_SORT))

if fileexists("data.ini") then

; ini Datei einlesen
$aProgramme = inireadsectionnames("data.ini")

; String für guictrlsetdata vorbereiten
$sData = ""
for $i = 1 to ubound($aProgramme)-1
$sData &= $aProgramme[$i] & "|"
next
$sData = stringtrimright($sData,1)

; Combo mit Daten befüllen
GUICtrlSetData($Combo1, $sData)

EndIf

Zitat von sklaim

EDIT: Ich kriege die Datei auch nicht exportiert, denn es tritt folgender Fehler auf: "Error: Binary integrity can't be verified."
Jemand eine Idee wie man das löst?

Keine Ahnung wovon du redest. Ich sehe in deinem Quellcode keine Exportfunktion für irgendetwas. Wo und bei was erscheint der Fehler denn?

Ich kann dir zwar nicht mit Sicherheit sagen warum das so ist, aber ich denke mal die Funktion MyErrFunc() wird mehr oder weniger "zwischendrin" ausgeführt und danach der fehlerhafte COM Aufruf beendet. Da es zum Fehler kam wird @error scheinbar dann beim Abschließen der COM Aktion verändert.

Einfachste Lösung: Verwende statt @error eine globale Variable die du im Code überprüfst bzw. in deiner Funktion MyErrFunc() veränderst.

Poste deinen Code bitte nochmal und verwende dabei den Quellcode Modus des Forums, damit deine Formatierung nicht verloren geht...

[Blockierte Grafik: http://i.imgur.com/eKu4eMm.png]

Was genau?

Die letzte Änderung liest zusätzlich noch den Schlüssel "SystemComponent" aus, welcher sich bei manchen Einträgen befindet. Meine Vermutung war, dass in der Systemsteuerung ausgeblendete Programme genau diesen Schlüssel mit dem Wert 1 besitzen, zumindestens ist bei mir soweit ich das beim groben Überfliegen gesehen habe keines der Programme sichtbar, welches diesen Schlüssel mit dem Wert 1 besitzt. Daher habe ich alle Einträge die diese Bedingung erfüllen mit continueloop übersprungen, genau wie ich es weiter oben bereits mit den Update/Hotfix Einträgen mache. In der Scite console lasse ich zur Kontrolle alle Einträge mit dem zugehörigen Schlüsselwert ausgeben, d.h. du könntest alle Zeilen die mit 1 beginnen mit der Systemsteuerung überprüfen um sicherzustellen, dass nicht zuviel übersprungen wird. Ich denke aber mal bei dir wird sich ebenfalls herausstellen, dass alle diese Einträge normalerweise ausgeblendet werden. Somit macht mein abgewandeltes Script vermutlich das gleiche wie die Routine der Systemsteuerung.