Beiträge von misterspeed

Zitat von Xorianator

Du hast 600 Zeilen Code - unkommentiert - hochgeladen. Da musst du den Köpfen hier auch mal Zeit lassen.
Wenn jemand Zeit & Lust hat wird er antworten

Das Problem ist eher die dürftige Beschreibung was er denn nun eigentlich will. Nach zweimal lesen habe ichs jedenfalls immernoch nicht verstanden. Vermutlich wird es klarer wenn man den Code ausführt, aber nur anhand des Postings wundert es mich nicht, dass noch kein Feedback hier kam.

Ich würde hier einen Screenshot empfehlen der zeigt was geändert oder eingebaut werden soll. Plus anständige Beschreibung was vorhanden ist, was genau nicht vorhanden ist und wie es genau sein soll. Nicht jeder hat Bock erstmal den Code auszuprobieren und durchzuwühlen nur um das Problem zu verstehen.

Zitat von NewVersionTester

und die Zeile 10 macht genau das rückgängig was auf Zeile 9 gemacht wird.

Nicht ganz. Er scheint hier die Schreibweise von "MP4" zu "mp4" ändern zu wollen. Dafür muss er den Zwischenschritt "mp" nehmen, weil ihm filemove() ansonsten vermutlich um die Ohren haut, dass die Ziel- und Quelldatei identisch ist, da Windows keinen Unterschied zwischen Groß- und Kleinschreibung macht.

Zitat von kogxi

Ich hätte probiert mit ControlClick die Buttons anzusteuern, aber ohne "id" o.ä. kann ich nur über die Koordinaten darauf zugreifen. Was bei einer Änderung der Fenstergröße und/oder Auflösung zu einem Fehlverhalten führt...]

Nunja, aber wenn es nur darum geht die GUI automatisiert zu testen, so sollte doch die Auflösung des Fensters statisch definierbar sein. Am Testrechner wird ja niemand nebenher arbeiten wollen. Dein Testscript könnte also z.B. die Fenstergröße selbst regulieren, du müsstest dann eben für die definierten Test Fenstergrößen jeweils die Koordinaten der Controls speichern (oder berechnen lassen, sofern der Algorithmus zur GUI Anpassung bekannt ist). Alternativ besteht noch die Möglichkeit durch optische Erkennung die Koordinaten der Buttons zu ermitteln. Imagesearch, Pixelsearch oder ein hier veröffenlichte Script das Icons/Bilder findet (Name ist mir entfallen) wären da entsprechende Ansätze.

Natürlich ist das alles unschön und nicht mit der Zuverlässigkeit von controlclick vergleichbar. Es gibt aber leider Fenster die keine Standardcontrols verwenden und nicht über die WinAPI/Autoit ansprechbar sind.

Weitere Infos zum verwendeten Buttonstyle findest du im übrigen hier:

http://msdn.microsoft.com/en-us/library/…v=vs.85%29.aspx

Demnach gibt es diesen Style erst ab Vista (oder ab einem gewissen Patch Stand auch ab XP ???). Sofern noch XP unterstützt werden soll müsstest du ggf. prüfen inwiefern sich das optisch auswirken kann.

Dein Script wird schon alleine deswegen nicht zuverlässig funktionieren, weil deine Titeldefinition nicht eindeutig genug ist. Die allermeisten Tooltips werden auf "[CLASS:tooltips_class32]" passen, dein Script könnte also die Transparenz eines völlig anderen Tooltips verändern wenn du Pech hast. Ein Tooltip ist prinzipiell nichts anderes als ein Fenster mit Controls. Du hast aber den Nachteil, dass du das eindeutige Fensterhandle nicht von der Funktion tooltip() zurückbekommst. Der Sinn eines Tooltips ist auch keine Overlay GUI für den Desktop, sondern ein Tooltip ist dafür da um ein Control näher zu beschreiben. Deswegen halte ich es für sinnvoller gleich ein eigenes Fenster zu verwenden. Dadurch hast du nicht nur eindeutige Daten um es zu verändern du hast auch wesentlich mehr Freiheiten in der Gestaltung des Fensters. Um Mouseover zu erkennen gibt es diverse Möglichkeiten. Ganz simpel z.B. mit mousegetpos() und wingetpos(). Wenn du danach googelst oder das Forum durchsuchst wirst du aber auch noch andere etwas effizientere Methoden finden.

Vielleicht ist das da eine Lösung für dich:

#include <ButtonConstants.au3>
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>

$Form1 = GUICreate("Form1", 615, 438, 192, 124)
$TTTCompStart = GUICtrlCreateButton("Überschrift", 30, 190, 180, 90, 14, -1)
$text = @CRLF & "Beliebiger Button Text" & @CRLF & "noch mehr text"
DllCall("user32.dll", "UINT", "SendMessage", "handle", GUICtrlGetHandle($TTTCompStart), "UINT", $BCM_SETNOTE, "ptr*", 0, "wstr",$text)

GUISetState(@SW_SHOW)

While 1
$nMsg = GUIGetMsg()
Switch $nMsg
Case $GUI_EVENT_CLOSE
Exit
EndSwitch
WEnd

1. Verwende bitte zusätzlich zum Spoiler zukünftig auch den BB-Code für Autoit Quellcode
2. Ich denke ein Blick ins Array Tutorial von Bugfix würde dir nicht schaden: http://www.bug-fix.info/array_tut.htm
3. Nun zu deinem Code... du sprichst immer nur die erste Datei des Arrays an ($aFiles[2]), du musst schon auch dein $i der Schleife nutzen, wie du es ja bereits richtig in der Funktion oeffnen() machst.

Hier die geänderte Version:

Sinnvoller wäre es aber den Programmierer für den Einsatz von Umlauten zu steinigen...
Deutsch ist ja schön und gut, aber beim Programmieren sollte man zumindestens auf Umlaute verzichten wenn es schon deutsche Funktions-/Methoden-/Klassennamen sein sollen.

Zitat von AspirinJunkie

Am einfachsten wäre wohl die Funktion FileChangeDir() zu nutzen.

Sollte nicht notwendig sein, denn der Funktion run() kann man auch explizit das workingdir mitgeben. Es sollte also reichen den run Aufruf so zu wählen:

Run(@scriptdir&"\batfile.bat",@scriptdir)

Du hast die Tatsache vergessen, dass in der letzten Spalte beliebig viele Leerzeichen erlaubt sind. Dein Script würde also nur den ersten Teil der Befehlsspalte ins Array schreiben...

Edit: Sorry mein Fehler, du splittest ja nicht alle Leerzeichen, somit sollte dein Script genauso funktionieren...

Naja was hast du nun als Quelldatei? Steht die Excel Tabelle zur verfügung? Wenn ja siehe Excel UDF. Wenn nur der Export der Tabelle als Textdatei zur Verfügung steht... warum exportierst du die Datei nicht mit brauchbaren Trennzeichen damit stringsplit() ohne weiteres nutzbar wird? Sollte nur der weniger brauchbare Export möglich sein, dann brauchst du eben minimale logik um das wieder auseinander zu fummeln:

ungetestet und nur fix im browser geschrieben...

#include <file.au3>
#include <array.au3>
global $aText = _filereadtoarray(...)
global $a2dResult[ubound($aText)][6] = [["Min","Std","Tag","Monat","Wochentag","Befehl"]]
for $i = 1 to ubound($atext)-1
$atemp = stringsplit($aText[$i]," ")
for $j = 1 to ubound($atemp)-1
if $j <= 5 then
$a2dResult[$i][$j-1] = $atemp[$j]
else
$a2dResult[$i][5] &= $atemp[$j] & " "
endif
next
$a2dResult[$i][5] = stringtrimright($a2dResult[$i][5],1)
next
_arraydisplay($a2dresult)

Nicht jedes Fenster hat einen Titel. Was macht die Funktion Tooltip() wenn man ihr "nichts" zum anzeigen gibt? Genau sie zeigt nichts an!

Zitat von 'Hilfe Auszug Tooltip()

Ein Tooltip bleibt sichtbar, bis das Skript schließt oder ToolTip("") aufgerufen wird.

Wie wärs mal mit ein wenig Debugging?

Bau ans Ende von jedem case eine Debug Meldung ein die dir den ermittelten Fenstertitel und die Variable des ausgelösten case anzeigt.
Beispiel:

...
Case $proxy1
WinActivate($proxy1)
Send($proxy_name)
Send("{TAB}")
Send($proxy_pwd)
Send("{ENTER}")
sleep(1000)
msgbox(0,"Debug","window title: " & @tab & $win & @crlf & "case variable: " & @tab & $proxy1)
Case $proxy2
...

Wundert mich wenig, dass dein Script unzuverlässig arbeitet.

Zum einen macht es keinen Sinn die Werte der Config Datei bei jedem Schleifendurchlauf zu lesen, das sind hunderte, wenn nicht tausende Festplattenzugriffe pro Sekunde. Lies die Config einmal bei Programmstart oder wenn unbedingt erforderlich periodisch alle 30 Sekunden oder so. (timerinit, timerdiff oder adlibregister wären hier deine Freunde). EDIT: Ok sehe gerade dein Sleep(100) in der Hauptschleife, das reduziert das lesen auf 10 mal pro Sekunde, dennoch unnötig und dein Script würde schneller reagieren wenn du das sleep weglässt und dafür das Lesen der Config aus der Schleife nimmst.

Nun hast du aber ein ganz anderes Problem. Angenommen das Lesen eines der Einträge aus der Config Datei schlägt fehl (z.B. weil nicht alle Werte eingetragen wurden), dann wird dir filereadline einen leeren String zurückliefern. Deine Switch case Verzweigung vergleicht diesen leeren String dann mit dem Titel des aktiven Fensters. Scheitert auch das lesen des aktiven Fenstertitels oder das Fenster hat schlichtweg keinen Titel, dann ist deine Bedingung erfüllt, obwohl du das mit Sicherheit nicht wolltest. Also wird dein Script lustig Daten senden.

Hier ist das nächste Problem... send() macht wenn ich mich recht erinnere Probleme in Verbindung mit Sonderzeichen, außerdem kann dein send irgendwo landen wenn der User irgendwohin klickt oder sich zufällig ein anderes Fenster in den Vordergrund drängelt. Deshalb solltest du dir statt send controlsend oder controlsettext und statt ENTER controlclick in der Hilfe anschauen.

Zitat von m.beyer

Habe meinen Vorgesetzten gefragt bzgl. dem Ansteuern via Mausklick. Auch dies wurde (o Wunder) abgelehnt.
Mein Vorgesetzter ist bei sowas recht nervig. Ich soll etliche Einstellungen im Thunderbird via Autoit automatisch konfigurieren. Damit alle Thunderbird Installationen (egal ob frisch oder bereits aktiv) die selben Einstellungen besitzen. Hierbei sollen einzig Tastaturbefehle (links/rechts/...) benutzt werden.

"Ignorant" war wohl noch eine schöne Umschreibung...

Hat dein Vorgesetzter überhaupt Ahnung von IT Angelegenheiten?

Vielleicht hilft ihm ja ein Vergleich um zur Besinnung zukommen:

Angenommen Azubi Nicole soll eine Glühbirne wechseln. Ihr Chef besteht aber darauf, dass sie nur den wackeligen 50 Jahre alten Hocker und keine Leiter dazu verwenden darf, außerdem muss sie dabei selbstverständlich die Kleiderordnung des Betriebes einhalten und Stöckelschuhe tragen... das ist nicht nur für Nicole gefährlich es besteht auch die Möglichkeit, dass die Glühbirne nie gewechselt wird, weil Nicole bei ihrem Versuch nicht nur vom Hocker fällt und sich das Bein bricht, sondern auch noch die Lampe von der Decke reist.

Spätestens jetzt sollte auch dein Vorgesetzter verstehen was er da von dir verlangt.

Die einfachste, zuverlässigste und absolut sinnvollste Möglichkeit alle Thunderbird Einstellungen in eurem Betrieb anzugleichen ist das automatisierte Ersetzen oder Editieren der bereits angesprochenen Konfigurationsdatei. Es gibt keinen logischen Grund diese Lösung abzulehnen. GUI Automatisierung mittels control* Funktionen ist deutlich weniger schön, aber immerhin noch recht zuverlässig, was im Falle von Thunderbird aber mangels Windows Controls ausscheidet. Automatisierung mittels Mausklicks und Tastenbefehlen ist absolut fehleranfällig, langsam und behindert den Anwender, die kleinste Änderung der GUI würde das Script untauglich machen. Das sollte niemals die angestrebte Lösung sein und nur dann genutzt werden wenn alle anderen Möglichkeiten technisch gesehen ausscheiden.

Ich würde meinem Vorgesetzten hier deswegen ganz klar sagen, dass er entweder eine zuverlässige und professionelle Lösung akzeptiert oder auf eine Lösung verzichten muss, denn letzlich bist du verantwortlich wenn diese hingefrickelte Lösung nicht zuverlässig funktioniert und mehr Schaden anrichtet als Nutzen bringt.

Naja das kann so nicht funktionieren. Dein Server kann dem Client nur dann antworten wenn er noch eine Verbindung zu ihm hat. Dein Client ist aber extrem kurz angebunden. Er verbindet sich, schickt seine Nachricht und trennt die Verbindung. Dein Server hat es genauso eilig. Sobald sich ein Client verbindet schnappt er scih sofort die Nachricht (sofern der client so schnell überhaupt eine senden konnte...), wertet diese aus und trennt die Verbindung zum Client.

Du solltest also Verbindungen unabhängig von der Kommunikation die eventuell stattfindet behandeln. Sprich dein Server nimmt erstmal Verbindungen an und speichert die Sockets dazu in einem Array. Danach prüft er für jeden Socket ob es Nachrichten gibt, wertet diese jeweils aus und entscheidet ob und was er antwortet. Dazu benutzt dein Server einfach tcpsend und den jeweiligen socket wie es auch der client tut. Erst wenn der Client eine Nachricht schickt, dass er die Verbindung trennen möchte darf der Server die Verbindung abbrechen und den Socket anschließend aus seinem Array mit den Sockets entfernen. Alternativ könnte auch der Server nach einer gewissen Zeit entscheiden die Verbindung zum Client zu trennen, der Höfflichkeit halber kann der Server dem Client dies vorher noch schnell mitteilen, damit dieser auch bescheid weiß, dass die Verbindung getrennt wurde.

Zitat von Make-Grafik

Hey, ich hab mir mal die Mühe gemacht und dein Skript ein wenig umgeschrieben sodass es effizienter und einfacher zu handhaben ist.

Das wird so sicher nicht funktionieren. tcpaccept() muss regelmässig abgefragt werden wenn sich Clients verbinden können sollen. Dein Script erlaubt nur zum Programmstart für wenige ms eine Verbindung, danach werden alle Verbindungsversuche ignoriert.

Einige Anmerkungen vorweg:

GUICtrlCreateEdit("", 24, 16, 385, 377)

Du solltest dem Edit auch eine Variable zuweisen, sonst kannst du es später weder auslesen noch mit Daten befüllen.

#include <ButtonConstants.au3>
if $i = "0" Then
...
ElseIf $i = "1" Then

Mach sowas bitte nie! Zahlen sollte man tunlichst nicht mit Strings vergleichen, andernfalls könnten ungewollte Ergebnisse rauskommen. Änder diese beiden Vergleiche besser mal.

Nun zum eigentlichen Problem:

Zum einen kann Autoit kein Multithreading, du wirst also immer das Problem haben, dass dein Code brav nacheinander und niemals zeitgleich abläuft.

Was man aber tun kann ist Code periodisch einschieben (Stichwort: Adlibregister).
Eine weitere Möglichkeit wäre es mehrere Prozesse zu verwenden. Das verlangt aber, dass deine Prozesse untereinander kommunizieren. Realisierbar ist das über jedemenge Methoden, z.B. TCP/UDP, Stdout/in, Namedpipes, Window Message uvm. (Stichwort: Interprozesskommunikation)

Problematisch ist es aber immer wenn man blockierende Funktionen wie msgbox() nutzt die das Script pausieren, da hilft dann auch Adlibregister oder die beste Interprozesskommunikation nichts mehr.

Eine mögliche Lösung ohne großen Aufwand wie z.B. multiple Prozesse oder der Einsatz von Adlibregister könnte so ausschaun:

Anmerkung:

Das Script erlaubt nur eine zeitgleiche Verbindung und erfordert den Neustart des Servers per Button wenn sich nochmal jemand verbinden können soll.
Außerdem sollte der client nach dem Verbindungsaufbau einige ms warten bevor er Daten sendet, da die Nachricht vom Server sonst möglicherweise nicht erfolgreich empfangen wird.
Der Client bleibt beliebig lange verbunden und kann beliebig viele Nachrichten an den Server senden.

Sollen mehrere Verbindungen möglich sein musst du die Verbindungs Sockets in einem Array speichern anstatt in einer einzigen Variable. Diesbezüglich sinnvolle Lektüre: http://www.bug-fix.info/array_tut.htm
Um getrennte Verbindungen (clients die offline gehen...) zu erkennen kannst du tcpsend an den Verbindungssocket nutzen und bei Misserfolg den Verbindungssocket reseten ($acceptedSocket=-1) oder aus dem Array entfernen. So werdn nicht mehr genutzte Sockets wieder für neue Clients frei.

Das ganze kann man natürlich noch deutlich weiter ausbauen, aber das würde nun zu weit gehen. Ich denke mit dem obigen Script hast du schonmal einen Ansatz wie man auch ohne Multithreading GUI und Funktionalität unter einen Hut bekommen kann. Wichtig ist nur, dass du die Hauptschleife nicht zu sehr verlangsamst oder gar blockierst.

Gibts keine bessere Methode das Ding zu automatisieren? Evtl. kannst du die Daten ja per Datei oder weiteren Parametern übergeben anstatt den "Fragendialog" zu automatisieren? Alternativ gibts auch den Quellcode zum Download wenn ich das vorhin recht gesehen habe. Wäre vermutlich nicht besonders schwer das ganze ein wenig abzuändern damit man die Daten mit einem einzigen Aufruf übergeben bekommt.

Sleep oder msgbox sollte man in Schleifen zum mitlesen des stdouts nicht wirklich verwenden, da dadurch ein erheblicher Teil des Outputs verloren gehen kann, wenn nicht gar alles (z.B wenn das Programm weniger als deine 100ms braucht...). Ich mache das deshalb immer so:

Func gpa_create_das_mainkey()
$pid = Run("C:\cryptconv\gpg\gpg2.exe --gen-key", @SystemDir, @SW_SHOW, $STDERR_CHILD + $STDOUT_CHILD + $STDIN_CHILD)
$sResult = ""
$sErr = ""
While 1
$sResult &= StdoutRead($pid)
If @error Then ExitLoop
WEnd

While 1
$sErr &= StderrRead($pid)
If @error Then ExitLoop
WEnd
consolewrite($sResult & @crlf)
consolewrite($sErr & @crlf)

EndFunc ;==>gpa_create_das_mainkey