Beiträge von misterspeed

Aber ich verstehe trotzdem nicht wozu es diesen Thread braucht. Wo ist das Problem bei google "autoit md5" oder "autoit md5 UDF" einzugeben, da sollten sich etliche Scripte finden um md5 hashes zu generieren. Ich würde außerdem testen was passiert wenn du die Parameter für die md5 hashes einfach weglässt, also ein unvollständiger POST, wie hier:

$html = _winhttpsimplerequest($connection, "POST", "forum/login.php?do=login","forum/login.php", "vb_login_username=c0w&vb_login_password=DEINPW&cookieuser=1&s=&securitytoken=guest&do=login")

Je nach PW ist es evtl auch notwendig die Werte der Parameter vorher noch nach URL encoded zu wandeln, damit es keine Syntax Kolisionen gibt.

Jupp, wie gesagt erstmal nur ein Grundgerüst um möglichst bequem überhaupt erstmal überall eine Zeitmessfunktion einzubauen, was doch etwas schwerer war als ursprünglich von mir angenommen. Schleifen sind jedenfalls angedacht, aber auch hier wird es evtl. nicht so einfach alle "do","for" und "while" statements zuverlässig zu finden ohne dabei versehentlich Kommentarzeilen oder Variablen zu ersetzen, das ist beim return statement schon ein rumgemurkse.

Hast du das Ding mal auf deine Scripte losgelassen und kontrolliert ob alle Funktionen und return statements korrekt erkannt und fehlerfrei ersetzt wurden?

Jede Programmzeile zu messen halte ich allerdings für übertrieben, außerdem würde die Laufzeit für die Messfunktion in den meisten Fällen die Ausführungszeit der eigentlichen Programmzeile deutlich übersteigen. Ich denke es genügt, wenn man einen ungefähren Anhaltspunkt bekommt in welchen Funktionen und ggf. auch Schleifen die meiste Zeit verlorengeht. Danach kann man immernoch manuelle Messpunkte in einzelnen Abschnitten setzen um das "Problem" einzugrenzen. Angedacht war aber noch eine globale Messung der Gesamtlaufzeit um z.B. errechnen zu können wie lange das Script im globalen Kontext arbeitet (z.B. GUI Schleife).

Was die Prozessorlast anbelangt...

Wie könnte man das am besten messen? Über das startende, also mein Script nehme ich mal an oder? Wenn ja wie misst man die Last einer bestimmten PID und wie würdest du die Lastmessungen am besten mit den Einträgen im Logfile verbinden? Timerinit Timestamps könnten zu ungenau sein um hier eine Zuordnung vorzunehmen, außerdem kann ich ja auch nicht 1000 Lastmessungen pro Sekunde machen und viele Funktionen laufen in weniger als 1ms durch.

Zitat von basementmedia

Damit man zu jedem Bauteil separat diese Nummer erfassen kann, muss die Liste auf die von mir beschriebene Weise aufgefächert werden, sodass man eben z.B. anstatt einer Zeile mit der Mengenangabe "2" zwei einzelne Zeilen hat um anschließend jeweils die Nummer eintragen zu können.

Aber ist das nicht eher die Beschreibung einer dritten Dimension? Nehmen wir nochmal meine Tabelle:

Name/Stufe	1	2	3	4	5	...
Schraube	3	4	3	0	0	...
Blech		1	3	0	4	0	...
BlaBla		0	0	0	1	2	...

Du kannst hier schonmal speichern, welche stufe wieviele Bauteile enthält. Wenn wir das nun in einem Würfel, also in einem 3D Array darstellen kannst du für jedes Bauteil jeder Stufe auch noch einen zusätzlichen Wert (deine Nummer/Gravur) speichern. Da ich das hier grafisch nicht wirklich darstellen kann versuche ich das mal in code auszudrücken:

Dim $aData[3][3][4] ; Aufbau: Dimension 1 sind die Namen/Bezeichnung der Bauteile, Dimension 2 sind die Stufen, Dimension 3 bietet Platz für die Gravur, die Anzahl der eingetragenen Gravuren entspricht der Anzahl der vorhandenen Bauteile einer Gruppe, das Array ist 1 basiert, index 0 wird jeweils zur Erläuterung der Datensätze oder der Angaben der Mengen verwendet

$aData[0][0][0]="*" ; die äussere Ecke des Würfels
$aData[1][0][0]="Schraube"
$aData[2][0][0]="Blech"

$aData[1][1][0]="Menge der Schrauben für Stufe 1"
$aData[1][2][0]="Menge der Schrauben für Stufe 2"

$aData[2][1][0]="Menge der Bleche für Stufe 1"
$aData[2][2][0]="Menge der Bleche für Stufe 2"

$aData[1][1][1]="Gravur der Schraube 1 von Stufe 1"
$aData[1][1][2]="Gravur der Schraube 2 von Stufe 1"
$aData[1][1][3]="Gravur der Schraube 3 von Stufe 1"

$aData[1][2][1]="Gravur der Schraube 1 von Stufe 2"
$aData[1][2][2]="Gravur der Schraube 2 von Stufe 2"
$aData[1][2][3]="Gravur der Schraube 3 von Stufe 2"

$aData[2][1][1]="Gravur des Blechs 1 von Stufe 1"
$aData[2][1][2]="Gravur des Blechs 2 von Stufe 1"
$aData[2][1][3]="Gravur des Blechs 3 von Stufe 1"

$aData[2][2][1]="Gravur des Blechs 1 von Stufe 2"
$aData[2][2][2]="Gravur des Blechs 2 von Stufe 2"
$aData[2][2][3]="Gravur des Blechs 3 von Stufe 2"

Also prinzipiell sollte das so schwer nicht sein, aber ich verstehe denke ich das System nicht ganz und bin mir auch nicht sicher ob es wirklich sinnvoll ist die Daten so zu strukturieren wie du das vor hast. Beim speichern von Daten sollte man immer zwei Dinge bedenken, zum einen sollte man Redundanz vermeiden, was schonmal für die ursprüngliche Speicherung spricht, zum anderen sollten die Daten so strukturiert sein, dass man sie leicht und schnell auslesen kann. Ich vermute du willst eine Art Organigramm oder eine Stückliste speichern, daher würde ich ein 2D Array nach diesem Schema verwenden:

Name/Stufe	1	2	3	4	5	...
Schraube	3	4	3	0	0	...
Blech		1	3	0	4	0	...
BlaBla		0	0	0	1	2	...

Aber vielleicht hab ich das auch falsch verstanden, was bei "Test" eben auch schwer nachvollziehbar ist. Vielleicht magst du nochmal genauer erklären woher die Daten stammen, wie sie aussehen wenn du sie bekommst, was du damit machen willst und warum du unbedingt diese Speicherstruktur haben möchtest.

Mehrdimensional ist im übrigen eine ziemlich unklare Aussage. Ist es nun ein 2D oder ein 3D Array?

Ich bastel gerade an einer Möglichkeit einfach und bequem meine Scripte zu analysieren und die Performance einzelner Funktionen zu messen.

Ziele:

1. Ermittlung der langsamsten Funktionen
2. Ermittlung der am meist aufgerufenen Funktionen
3. Ermittlung der insgesamt zeitintensivsten Programmteile
4. Eventuell grafische und zeitliche Darstellung des Scriptablaufs (Sequenzdiagramm)

Die aktuelle Version erstellt ein "Trace" Script aus dem Quellscript, startet dieses und gibt die Ergebnisse der Messungen aus. Derzeit fehlt also noch eine Auswertung (sollte kein Problem sein) und grafisch ansprechende Darstellung (schon eher ein Problem).
Außerdem fehlt es mir an entsprechend umfangreichen Testscripten um die Funktionalität der aktuellen Fassung zu testen.

Und ja der Quellcode schaut derzeit noch etwas chaotisch aus, gerade was das einfügen bei "return" statements angeht musste ich lange rumspielen bis es mit meinem Testscript zuverlässig funktioniert hatte. Vermutlich wäre der Einsatz von regulären Ausdrücke deutlich einfacher gewesen, steht jedenfalls auf meiner Todo das nochmals etwas zu ändern.

Ich möchte euch daher erstmal darum bitten das Script ausgiebig mit umfangreicheren Scripten zu testen und mich auf Fehler aufmerksam zumachen (z.B. nicht ersetzte oder falsch ersetzte "return" Strings). Ich bin mir auch nicht sicher ob das Script funktioniert wenn im Original Script bereits ein "onautoitexitregister" verwendet wird und wie ich das in solch einem Fall evtl. besser lösen könnte ohne permanent in die Datei schreiben zu müssen. Theoretisch wäre auch ein überwachendes Script denkbar um erst garkeinen Umweg über eine Datei gehen zu müssen, allerdings möchte ich die Performance des Scriptes auch nicht zu sehr durch die Messungen und Datenübertragung der Messergebnisse beeinflussen.

Ideen, Vorschläge oder gar modifizierte/erweiterte Scriptversionen sind herzlich Willkommen.

EDIT: Netter Nebeneffekt ist im übrigen, dass man bei abstürzenden Scripten sehr gut im Logfile sieht welche Funktion zuletzt ausgeführt wurde, was die Fehlersuche bei kompilierten Scripten evtl. ein wenig vereinfachen kann.

ShellExecuteWait($vlc & $parameter & $film) ; funktioniert nicht

Aber auch nur weil du shellexecute genauso falsch verwendest wie der Threadstarter. Im Gegensatz zu run verlangt shellexecute die Angabe der cmdline Parameter als zweiten Funktionsparameter, das hier sollte also genauso funktionieren:

ShellExecuteWait($vlc , $parameter & $film)

Davon ab verwendet man shellexecute aber ohnehin nur, wenn man das Programm mit welchem die Datei geöffnet werden soll nicht festlegen möchte, sondern das hinterlegte Standardprogramm verwenden möchte. Es macht also wenig Sinn bei Nutzung von shellexecute die vlc.exe anzugeben, stattdessen reicht wie Friesel ja bereits gezeigt hat ein einfaches

ShellExecuteWait($film)

Wenn man hingegen ein bestimmtes Programm verwenden möchte nutzt man eher run().

Bedenke aber, dass im Falle einer Endlosschleife der Server immer sofort in den Standby geht, wenn du ihn aufweckst ohne zuvor eines der anderen Geräte zu starten. Es könnte außerdem passieren, dass der Server nach dem Aufwachen ein wenig braucht, bist sein Netzwerk wieder voll funktionsfähig ist und die Pings daher scheitern. Das würde ebenfalls in einer permanenten Standby Schleife enden, daher schlage ich vor das Script wie folgt zu ändern:

Global $aIP[3]=["192.168.2.100","192.168.2.101","192.168.2.102"]
Global $bAwake = True

while 1
for $i = 0 to ubound($aIP)-1
$bAwake = False
if ping($aIP[$i])>0 then
$bAwake = True
exitloop
endif
next
if $bAwake = False then Shutdown(64)
sleep(60000) ; nach dem Aufwachen oder bei erfolgreichen Pings erstmal schlafen, bevor wieder geprüft wird, das lässt dir Zeit das Script zu beenden, sofern notwendig
wend

Dann solltest du mein Script aber ändern, denn wenn du den "Server" wieder aufweckst sollte das Script ja ebenfalls laufen, damit der Server später wieder in den Standby gehen kann. Sprich du brauchst eine Endlosschleife und müsstest daher "while 1" statt "while $bAwake" verwenden, derzeit würde sich das Script nach einmal Standby beenden.

Ok meinetwegen, aber wie geht er wieder an, wenn er gebraucht wird? Im Standby Modus läuft dein Script jedenfalls auch nicht mehr, für den "Server" ist es also nicht mehr möglich sich selbst aufzuwecken wenn er erstmal im Standby ist.

Global $aIP[3]=["192.168.2.100","192.168.2.101","192.168.2.102"]
Global $bAwake = True

while $bAwake
for $i = 0 to ubound($aIP)-1
$bAwake = False
if ping($aIP[$i])>0 then
$bAwake = True
exitloop
endif
next
if $bAwake = True then sleep(60000)
if $bAwake = False then Shutdown(64)
wend

Zitat von xsibit666

Sry aber der fügt den text irgendwie anders ein als er bei mir aussieht

Dann verwende nicht den normalen Editor beim Posten im Forum, sonderen den zweiten Tab "Quellcode".

Und was deine dürftige Erklärung angeht was du eigentlich machen willst solltest du auch nochmal in dich gehen und dir (wie bereits erwähnt wurde) mehr Mühe geben dein Anliegen verständlicher zu formulieren.

Dein derzeitiger code funktioniert jedenfalls sicher nicht so wie du es gern hättest. Du machst zwar Pings auf alle drei Rechner prüfst aber nur einmal auf @error und zwar nur beim letzten Ping. Ist der als einziger nicht erfolgreich fährt dein PC in den Standby, ist er als einziger erfolgreich schläft dein PC und prüft 60 Sekunden später erneut.

Die Frage ist nun aber was du eigentlich haben willst? Soll dein PC immer in den Standby gehen, wenn ein einziger der 3 Rechner nicht erreichbar ist, soll er nur in den Standby gehen wenn alle nicht erreichbar sind? Warum willst du überhaupt, dass dein PC in den Standby geht, wenn die anderen aus sind? Bist du sicher, dass Ping eine zuverlässige Methode ist um festzustellen ob andere Rechner im Netzwerk an sind? Pings können auch scheitern, wenn dein Netzwerk überlastet, gestört (schlechte WLAN Verbindung) oder wenn einer der Zielrechner bzw. dein Router ICMP Pakete blockt. Ich würde das ganze daher überdenken.

[Blockierte Grafik: http://i.imgur.com/WvOuzAk.jpg]

...und nein Autoit braucht kein NetFramework, davon ab ist das in Windows 7 ohnehin enthalten. Poste einen Beispielquellcode bei dem der Fehler auftritt, ansonsten musst du den Fehler wohl selbst finden.

Ich würde sagen das einzige was du hier hast ist ein Anzeigebug, weil das Fenster nach dem Verschieben nicht neu gezeichnet wird. Klick zwei oder dreimal auf ok und schieb das Fenster dann kurz außerhalb des sichtbaren Desktopbereichst. Du wirst danach sehen, dass nur das Groupcontrol und nicht der Button verschoben wurde. Der Button ist nachwievor an seiner ursprünglichen Position und kann auch dort geklickt werden. Das Anzeigeproblem kannst du vermutlich mit der "redraw" Funktion (keine Lust nachzusehen wie sie genau heißt) in den WinAPI Funktionen in den Griff bekommen. Das eigentliche Problem, dass das Button Control nicht verschoben wird bekommst du wohl nur durch ein separates controlmove für alle betroffenen Controls gelöst. Die Hilfe spricht auch klar von einer visuellen Gruppierung, welche insbesondere bei Radio Buttons auch Auswirkungen auf die Klickbarkeit hat. Dass alle controls einer group aber zusammenhängen sollen wird dort nicht erwähnt und entspricht auch nicht meinen bisherigen Beobachtungen. Um das Verschieben einer ganzen Gruppe zu vereinfachen kann man aber die controlid des group Beginn und group Ende in einer Schleife verwenden.

Zitat von Freaky

Okay, lustigerweise reicht einfach der Befehl "w32tm /resync" aus

Ja weil Windows standardmässig schon einen Zeitserver konfiguriert hat, die erste Zeile ist wie bereits erwähnt nur zum ändern des Servers gedacht. Das Script lief damals btw unter Windows XP, durchaus möglich, dass dies unter Vista/7/8 mittlerweile wie in deinem cmdline output angedeutet auch über die w32tm.exe geht.

EDIT:

w32tm /config [/computer:<Ziel>] [/update]
    [/manualpeerlist:<Peers>] [/syncfromflags:<Quelle>]
    [/LocalClockDispersion:<Sekunden>]
    [/reliable:(YES|NO)]
    [/largephaseoffset:<Millisekunden>]
  computer:<Ziel>        - Passt Konfiguration des <Ziels> an. Ohne Angabe
    dieses Parameters wird der lokale Computer verwendet.
  update               - Benachrichtigt den Zeitdienst über
    Konfigurationsänderungen, damit die Änderungen wirksam werden.
  manualpeerlist:<Peers> - Richtet die manuelle Peerliste mit <Peers> ein.
    Dies ist eine Liste von DNS- bzw. IP-Adressen, durch Leerzeichen getrennt.
    Bei mehreren Peers muss diese Option in Anführungszeichen angegeben
    werden.

Darüber kannst du auch eigene Zeitserver hinterlegen, sofern notwendig. Deine Peerliständerung kannst du dann mit dieser Zeile prüfen:

w32tm /query /peers

EDIT2:

Ahja hier wird beschrieben wo man in der Registry das Aktualisierungsintervall in Sekunden ändern kann: http://www.rz.uni-osnabrueck.de/Dienste/NTP/win7.htm
Es ist also nicht notwendig die Aktualisierung durch die resync Zeile von Hand anzustossen, es würde auch reichen die Aktualisierung auf einmal pro Tag oder Stunde zu ändern. Eine starke Abweichung der Zeit nach wenigen Tagen deutet aber im übrigen auf eine fast leere cmos Batterie hin.

Ich verwende in einem meiner Scripte diese 3 Zeilen, die erste setzt einen beliebigen Timeserver. Wo genau der Unterschied zwischen den anderen beiden lag und warum ich letzlich beide verwende ist mir atm nicht mehr ganz klar, aber es hatte jedenfalls funktioniert und bewirkt, dass die Zeit anhand des gesetzten Timeservers sofort synchronisiert wurde.

RunWait(@ComSpec & " /c " & "NET TIME /setsntp:" & $timeserver,"",@SW_HIDE)
RunWait(@ComSpec & " /c " & "w32tm /config /update","",@SW_HIDE)
Run(@ComSpec & " /c " & "w32tm /resync /nowait","",@SW_HIDE)

Sehe aber gerade, dass das im Link von i2c erklärt wird...

Du wirst vermutlich nur die letzte Zeile ab und an aufrufen müssen, allerdings ist das Standardintervall (1 Woche?) welches Windows für die Aktualisierung verwendet glaube ich auch änderbar, was wohl sinnvoller wäre als permanent selbst eine Synchronisation anzustossen.

Dass deine GUI nicht auf Eingaben reagiert liegt sehr wahrscheinlich an deinen Sleeps. Solange das Script schläft verbleibt es in genaue dieser Zeile und macht garnichts. Damit deine GUI möglichst sofort reagiert sind sleeps in GUI Schleifen grundsätzlich zu vermeiden. Grundsätzlich sollte man den Code in der GUI Schleife auch übersichtlich halten, sprich alles was mehr als 3,4 Zeilen braucht lagert man in Funktionen aus, welche unterhalb der GUI Schleife folgen. Aber auch hier musst du darauf achten, dass sich dein Script nicht zulange in der aufgerufenen Funktion befindet, da dies natürlich genauso die Auswertung der GUI Nachrichten blockiert (zur Not kann man guigetmsg aber auch innerhalb einer Funktion verwenden um auch dort GUI Nachtrichten auszuwerten). Mir fehlt jetzt die Lust dein Script umzubauen, aber prinzipiell würde ich timerinit, timerdiff und ggf. eine globale flag Variable verwenden um bestimmte Aktionen nach einem bestimmten Ereignis und erst nach Ablauf einer bestimmten Zeit auszuführen. Das erfordert aber einen grundsätzlichen Umbau deines Programms.

Wenn du meinen Link gelesen hättest wüsstest du, dass "services" nur vor Windows XP, aslo Win95/98 vor dem Beenden schützbar waren, seit XP funktioniert das nicht mehr, sprich services können beliebig über den Taskmanager beendet werden. Ausnahme sind einige wichtige Systemservices unter Windows XP die anhand ihres namens geschützt werden, steht aber auch alles in meinem Link von oben. Das wird dich also nicht weiterbringen, selbst wenn du es hinbekommst einen Service zu registrieren.

Bezweifle ich, aber um das Ein und Ausblenden vieler Controls zu erleichtern kann man dummycontrols verwenden:

$startIDGroup1 = guictrlcreatedummy()
;...hier erstellst du deine controls
$endIDGroup1 = guictrlcreatedummy()

; alle unsichtbar:
for $i = $startIDGroup1 to $endIDGroup1
guictrlsetstate($i,$GUI_HIDE)
next

sleep(5000)

; alle sichtbar:
for $i = $startIDGroup1 to $endIDGroup1
guictrlsetstate($i,$GUI_SHOW)
next

EDIT:

Eine weitere Alternative wären getrennte Fenster die man abwechselnd sichtbar oder unsichtbar macht, was nun geschickter ist muss man von Fall zu Fall entscheiden.

Wie sollte ich dir darauf eine Antwort geben können, ich kenne den restlichen Code nicht und kann somit nicht nachvollziehen was du wann und wie machst. Tatsache ist aber, dass eine nicht deklarierte aber in der gui Schleife verwendete Variable zum Absturz führt. Eine deklarierte Variable mit Wert 0 führt hingegen zu ungewünschtem Verhalten wie du ja selbst festgestellt hast.

Lösungen:

1. Das Control von Anfang an erstellen, kann ja unsichtbar sein und später auch mit guictrlsetdata verändert werden bevor du es sichtbar machst
2. Weise bei der Deklaration einen Wert zu, welcher niemals von guigetmsg zurückgegeben wird, z.B. -99999999999 oder so, dabei aber vorsichtig sein, da guigetmsg durchaus auch negative Werte annehmen kann
3. Alternativ kannst du auch den Case 0 abfangen, z.B. in dem du die switch case Verzweigung in eine if Bedingung setzt, also die switch case Verzweigung nur ausgeführt wird wenn $msg <> 0
4. Oder du fängst den case 0 ganz am Anfang der Switch Case Verzweigung ab und machst in diesem Case eben garnichts

EDIT: Ja genau das wollte dir Bugfix sagen

So schnell landet man also vom Papierkorb suchen beim "laden einer Webseite" aka Spielebot... lies bitte die Forenregeln.

Deine Switch case Sache kannste schonmal rauswerfen, ziemlich unnötig tausend cases zu machen wenn du sowieso immer das selbe tust, nämlich die $msg an die Funktion _menu() weiterreichen. Das ganze kann also wie folgt zusammengefasst werden:

$msg = GUIGetMsg()
Switch $msg
Case $GUI_EVENT_CLOSE
_Exit(); Wenn X gedrückt wird, wird _Exit Funktion aufgerufen

Case $WelcomeItem, $SuchenItem, $GUI_Button02
consolewrite("gui msg: " & $msg & " wert von gui_button02: " & $GUI_Button02 & @crlf)
_Menu($msg)
EndSwitch

for $i = 1 to 15
if $msg = $SuchenItemSub[$i] then _Menu($msg)
next
WEnd

Wo dein Fehler liegt kann ohne den restlichen Code niemand sagen, denn dazu müssten wir wissen warum der Case $GUI_Button02 fälschlicherweise aufgerufen wird. Ich tippe darauf, dass du die Variable nur deklariert hast, aber beim ersten Durchlauf der Switch Case Verzweigung noch keinen Wert zugewiesen hast. Dadurch hat die Variable noch den Wert 0. Wenn man nichts angeklickt hat liefert guigetmsg soweit ich mich erinnere immer 0. Somit ist der Case erfüllt wenn man nichts tut und die Funktion wird aufgerufen.

Um das zu prüfen hab ich oben mal ein consolewrite eingebaut.