Beiträge von misterspeed

Bei einem Broadcast ist dem Sender aber nicht bekannt wieviele Empfänger es gibt und somit kann er auch nicht wissen wer alles drauf antworten sollte.

Warum versendest du überhaupt einen Broadcast? Auch eher ungewöhnlich ist es doch, dass du viele Server und wenige Clienten hast, warum nicht einen fixen Server im Netz und viele Clienten, die sicht automatisch beim Server anmelden (sofern erreichbar). Dann weiß dein Server welche clienten vorhanden (online) sind und kann Befehle an diese dauerhaft verbundenen Clienten senden. Grundsätzlich sollte TCP bei direkter Unicast Kommunikation auch gewährleisten, dass alles da ankommt wo es hin soll. Zur verifizierung auf Protokollebene könntest du aber auch auf eine Bestätigung der Clienten warten, dass der Befehl angekommen, verstanden und ausgeführt wurde.

Zitat von Make-Grafik

Dazu der Inhalt der Output.exe:

[autoit]

ConsoleWrite('Make-Grafik')

[/autoit]

Frage 1: Wieso liest StdoutRead nichts aus aber dafür StderrRead?

Sofern deine Output.exe wirklich nur diese eine Zeile enthält wird es daran liegen, dass die Output.exe längst beendet ist bevor das erstemal versucht wird den stdout stream zu lesen. Dies scheitert dann einfach, weil der Prozess nicht mehr existiert.
Du solltest also ein kurzes sleep ans Ende der Output.exe setzen, damit das lesende Script noch die Möglichkeit hat den stdout Buffer auszulesen.

Zitat von JaneDoe

Ich denke nach dem ganzen Geschreibe raucht euch auch der Kopf

Bilder sagen manchmal mehr als tausend Worte. Unter deinem Text kann man sich alles Mögliche vorstellen. Ich habs zumindestens nicht kapiert was du nun eigentlich für eine GUI hast, wie es derzeit realisiert ist und was zukünftig besser sein soll. Ein abgespeckter Quellcode der das Problem veranschaulicht und einem die Möglichkeit gibt eine Lösung zu testen wäre auch nicht verkehrt.

Aber mal rein mathematisch betrachtet:

Du willst, dass sich ein Kreis proportional zur GUI Größe vergrößert oder verkleinert.
Du hast einen Referenzwert für den Radius bei einer fixen GUI Auflösung. Wenn du die GUI nun mit gleich bleibendem Seitenverhältnis vergrößerst oder verkleinerst, dann gilt:

$radiusNEU / radiusALT = GUI_BreiteNEU / GUI_BreiteALT

daraus folgt: $radiusNEU = (GUI_BreiteNEU / GUI_BreiteALT) * $radiusALT

Vielleicht hilft dir der Ansatz ja.

EDIT:

Da der Kreismittelpunkt vermutlich fixe x und y Koordinaten hat muss dieser vermutlich noch um die Hälfte der GUI Verbreiterung nach rechts verschoben und um die Hälfte der GUI Erhöhung nach unten verschoben werden.

Aber wozu extra einen fremden Server anpingen? Es würde doch auch genügen einfach dort auf Fehler zu prüfen wo man zum ersten mal versucht eine Internetverbindung aufzubauen. Jede Funktion sollte über entsprechende Error Codes und Rückgabewerte verfügen. Wenn du prüfen willst warum dein Programm keinen Internetzugang hat kannst du das jedenfalls nicht mit einem Ping prüfen, weil dieser ebenfalls von der Firewall/Antiviren Lösung geblockt würde. Stattdessen müsstest du eher prüfen ob der PC eine aktive Internetverbindung hat und danach abgleichen ob du selbst auch Zugang hast, wenn nein (Fehler der Funktion) ist eine Firewall oder Antiviren Lösung höchstwahrscheinlich verantwortlich.

Zitat von PCMader

Problem gelöst!!

Hallo alle Zusammen,

ich konnte das Problem mit Hilfe der Idee von autoBert lösen.

Hier für alle, welche auch ein ähliches Problem haben, der erweiterte Code:

[autoit]

$sCommand = ' /c mkvmerge.exe -o ' & $Datei_mkv2 & ' ' & $Datei_2642 & ' ' & $Datei_mp22
;~ ConsoleWrite($sCommand & @CRLF)
RunWait(@ComSpec & $sCommand, 'C:\mkvToolNix\')

[/autoit]

Das wird aber teilweise zu Problemen führen, immer dann wenn sich Leerzeichen in einem der Pfade / Dateinamen befinden. Besser wäre es die Parameter sauber mit Anführungszeichen zu trennen:

$MKVmergePath = "c:\mkvToolNix 5.1\mkvmerge.exe" ; Pfad mit Leerzeichen

$sCommand = '"' & $MKVmergePath & '" -o "' & $Datei_mkv2 & '" "' & $Datei_2642 & '" "' & $Datei_mp22 & '"'
;~ ConsoleWrite($sCommand & @CRLF)
RunWait($sCommand)

Naja so wie ich dein Script anschaue ist dein Ping doch ohnehin sinnfrei, da du das eventlogOpen und eventlogCount auch dann machst, wenn der Rechner nicht auf einen Ping reagiert hat. Das wäre im Übrigen auch mein Änderungsvorschlag. Lass den Ping weg und reagiere einfach auf den Fehlerrückgabewert von eventlogOpen. Wenn das Handle nicht erstellt wird gehts mit dem nächten Rechner weiter (continueloop).

EDIT:

Until Not ProcessExists('cmd.exe')

Schlechte Idee, was passiert wohl wenn zufälligerweise noch eine andere cmd.exe Instanz neben den unzähligen Pings existiert? Richtig, Endlosschleife!

Zwar verständlich, aber was erwartest du nun großartig an Fehleranalyse? Als langjähriges und erfahrenes Mitglied sollte dir selbst klar sein, dass man mit den wenigen Informationen ohne Script keinerlei Aussage über die Fehlerursache machen kann.
Da bleibt eigentlich nur noch Autoberts Tipp und selbst suchen.

Was mich an deiner Aussage irritiert, ist dass die Logdatei weg sein soll. Ist die Datei nun wirklich weg (gelöscht), garnie erstellt worden oder einfach nur leer? Ersteres kann ja nur dann vorkommen wenn...

- es mit filedelete gelöscht wird
- oder mit filemove irgendwohin verschoben wird

Die dafür in Frage kommenden Zeilen finden sollte ja kein Problem sein. Insbesondere sollten dabei auch die verwendeten eigenen includes und ggf. die DLLs geprüft werden. Weitere Möglichkeiten wären...

- dass es an einem Ort gespeichert wird, welcher von einem externen Programm bereinigt wird. Also z.B. das Temp Verzeichnis des Benutzers plus ein entsprechendes Tool zum säubern der Tempfiles
- dass es an einem Ort gespeichert wird der inkonsistent ist, z.B. RamDisk, oder defekter Datenträger, evtl externer Datenträger wie Netzlaufwerk oder USB-Stick
- oder aber ein doofer Anwender der die Datei von Hand löscht (unwahrscheinlich)

Sollte die Datei nur leer sein, dann kommen alle filewrites dafür in Frage. Da mir selbst schonmal eine Statistik Datei genullt wurde erstelle ich grundsätzlich vor dem Filewrite ein Backup und prüfe nach dem Filewrite die Größe der Datei, ist diese kleiner als das Backup (oder 0) wird das Backup wieder zurückgespielt.

Ob die Datei überhaupt immer erstellt wird kann einfach mit fileexist geprüft werden, sofern das nicht ohnehin schon getan wird. Vielleicht verhindert UAC oder die Schreibberechtigung des Benutzers ja die Erstellung des Logfiles?

Zitat von AspirinJunkie

Es ist ziemlich ineffizient permanent AutoIt prüfen zu lassen ob sich eine Datei geändert hat.
Windows schmeißt in einem solchen Falle eh eine Meldung so dass man AutoIt einfach auf diese warten lassen und ansonsten schlafen lassen kann.

Das ist zwar etwas aufwändiger umzusetzen aber wenn es dann mal funktioniert ist diese Lösung deutlich eleganter.

Nice, das landet mal in meiner Script Sammlung.
Kann ich sehr gut gebrauchen, hab etliche Scripte die Dateien oder Ordner periodisch auf Veränderung prüfen.

Wie schon gesagt wurde, am besten postest du diese Funktion. Möglicherweise hast du einen Fehler eingebaut, der zu einer endlosen Rekursionsschleife und letzten Endes zum Absturz führt. Sollte das nicht der Fall sein bleibt nur ein Umschreiben des codes. Enweder beschränkst du die Rekursion auf eine fixe Ebenenanzahl (siehe oben per Zähler), was dann aber je nach Funktion eben problematisch ist, weil die Operation frühzeitig und somit unvollständig beendet wird, oder aber du überlegst dir wie du das Problem teilweise oder komplett ohne Rekursion lösen kannst.

Zitat von Andy

Einzig die maximale Rekursionstiefe ist festgelegt. Lt. Hilfe mit 389 Schritten, aber ich bekommen beim Testen mehr...

Woher stammt diese Zahl? Ich finde unter den Limits lediglich die Zahl 5100, welche sich auf die maximale Rekursionstiefe von call() und execute() bezieht.

Spielt ja wohl kaum eine Rolle bei derart kleinen Abweichungen.

Ich würde einfach mal vermuten, dass Windows dafür verantwortlich ist. Vermutlich werden je nach allgemeiner Systemauslastung mal ein paar kb mehr oder weniger in der Auslagerungsdatei ausgelagert, was dann natürlich auch zu abweichendem physikalischem RAM Verbrauch führt. Oder Teile deines Scriptes erzeugen dynamische Daten, welche eben mal mehr und mal weniger viel Speicherplatz benötigen.

Zitat von Zattoo

weiß keiner ne lösung?

Spoiler anzeigen

[autoit]

Func _LoadSettings()
$Key = IniReadSection(@ScriptDir & "\" & $Name & "\" & $Name & ".ini", $Name)
If Not @error Then
For $o = 1 To $Key[0][0]
$a = _StringEncrypt(0, $Key[$o][0], $PW, $LV)
$b = _StringEncrypt(0, $Key[$o][1], $PW, $LV)
Assign(StringTrimLeft($a, 1), $b)
$c = Eval("a")
ConsoleWrite($c & " " & $a & @CRLF)
GUICtrlSetData($a, $b)
Next
EndIf
EndFunc

[/autoit]

Alles anzeigen

Immernoch der selbe Fehler, siehe Punkt 3 von oben. Hier nochmal was du machst:

$a = "$test"
$b = "testwert"
$test = "testwert" ; dein assign()
; $c="$test" ; sowieso nur debugging...
guictrlsetdata("$test","testwert") ; total falsch, ein string ist keine control ID, selbst wenn du stattdessen
; die neu erstellte Variable $test verwenden würdest stünde da nur der Wert "testwert" und keine control ID

Ansonsten wie schon gesagt... sinnfreies Konzept, keine lauffähigen Testscripte --> keine besonders gute Aussichten auf Support

Man kann den Zugriff auf den Taskmanager auch per Registry Eintrag verhindern.

http://www.wintotal.de/tipparchiv/?TID=1026

Zitat von raigon

Allerdings möchte er das Script nicht ausführen, sobald ich es von einem Gastkonto aus öffne ... er hat dann ne Art Dauerlade-Symbol und ist am flackern. (Windows Vista Home Premium)

Vermutlich ein Problem mit UAC und dem #requireadmin. Jedenfalls hatte ich damit schon ein vergleichbares verhalten. Würde es daher an deiner stelle mal ohne requireadmin versuchen.

Was ein Bild anstelle eines einfarbigen Hintergrunds angeht schaust du dir am besten

guictrlcreatepic()

in der Hilfe an.

Ist ja auch klar, weil man bei Listviews mit mehreren Spalten die Werte jeder Spalte mit Trennzeichen angibt:

GUICtrlCreateListViewItem("wert_spalte1|wert_spalte2", $processlist)

Ausserdem kann nur ein wie oben gezeigter String an die Funktion übergeben werden, nicht ein komplettes Array, wie du es von processlist() bekommst. Du musst dir diesen String also zunächst selbst "bauen":

GUICtrlCreateListViewItem($aprocess[1][0] & "|" & $aprocess[1][1], $processlist) ; das zeigt den ersten prozess und die zugehörige id an

In deiner Schleife würdest du dann eben die Zeile durch $i ersetzen und so alle Infos des Arrays ins Listview verfrachten.
Außerdem war ich mal so frei die Schleife so zu ändern, dass du wirklich nur die Prozesse erhältst, denn diese fangen erst bei 1 an, in Zeile 0 des Arrays steht lediglich wieviele Treffer gefunden wurden.

Kurze Antwort: Nein iniread() kann keine Dateien von Webservern, sondern nur lokal vorhandene Dateien verarbeiten.

Eine Datei von einem beliebigen Webserver kannst du mit

InetRead()
; oder
InetGet()

einlesen. Inetread speichert hierbei den kompletten Dateiinhalt in einer Variable, inetget hingegen speichert die Datei auf der Festplatte. Du kannst also inetget verwenden und im Anschluss die iniread Funktion für deine neue lokale Datei anwenden. Sofern du keine lokale Kopie der ini haben willst kommst du nicht drum herum dir deine eigene ini Funktion zu schreiben, die den String von inetread parsed.

Glaube hier kapiert keiner was du eigentlich erreichen willst, warum sollte dir ja mittlerweile bekannt sein, aber lassen wir das...

Um mal zusammenzufassen was deine Schleife da macht:

1. Den Namen der neuen Variable und dessen neuer Wert aus einer ini entschlüsseln, soweit ganz toll, sofern deine encrypt Funktion richtig angewendet wird, zum testen würd ich diese crypt Kacke vllt erstmal weglassen...
2. Nun erstellst du mit assign() eine Variable mit diesem entschlüsselten Namen (vermutlich wird das ohne dritten Parameter intern per dim deklariert also innerhalb der Funktion als lokale Variable erstellt, ausser sie existiert bereits vor Aufruf global, wovon ich nicht ausgehe, die Variable ist ausserhalb dieser load Funktion also total wertlos und nicht existent), dazu weist du ihr keinen / einen leeren Wert zu --> "", spätestens hier solltest du ihr vllt eher eine ControlID zuweisen... seihe 3.
3. Danach kommt das sinnfreiste: Du tust so als ob der entschlüsselte Variablenname $a eine ID eines bestehenden Controls wäre. ($a ist aber "$variable", also nur ein String, mehr nicht)... somit wirst du wohl auch kaum irgendeinem Control etwas zuweisen können, denn du hast garkein Control erstellt und demzufolge auch guictrlsetdata nicht richtig angewendet.

Was 2. angeht siehe Hilfe, da wird der 3. funktionsparameter erklärt. Was 3. angeht erschliesst sich mir nachwievor der Sinn deiner ganzen Vorgehensweise nicht. Wurde hier denke ich auch schon erwähnt, dass es keinen Sinn macht Variablen dynamisch so zu erstellen wie du das gern haben willst. wenn man GUI's dynamisch erstellen und Werte dynamisch aus ini Dateien zuweisen will verwendet man arrays um sowohl die Controlid als auch den Wert des Controls zu speichern, alles andere macht keinen Sinn. Im Script spricht man die betreffenden Controls dann eben nicht per Variablenname an, sondern einfach per Array Index in Schleifen. Aber ohne Script wie immer sinnlos da näher darauf einzugehen...

Grundsätzlich sehe ich hier weder ein Pro noch ein Contra Autoit. Auch mit Autoit kannst du einen Registry Zweig rekursiv durchsuchen, allerdings gibt es dafür denke ich keine fertige Standardfunktion, wie den DOS Befehl "reg query". Du müstest also die Suche mithilfe der wenigen verfügbaren Registry Funktionen von Autoit selbst programmieren, was durch den Einsatz von Schleifen und rekursiven Funktionsaufrufen kein Problem sein sollte. Ok mit deinen Autoitkenntnissen vielleicht schon...

Da die Suche per Batch unter XP aber bereits erfolgslos ist vermute ich mal, dass auch eine Autoit Umsetzung davon nichts finden würde. Wäre es vielleicht denkbar, dass eine oder mehrere dieser Dinge verantwortlich sind?

1. Eure XP clients haben garkein Outlook 2010, sondern noch eine ältere Version. Demzufolge befindet sich der Registry Eintrag vielleicht an ganz anderer Stelle, oder existiert eben garnicht?
2. Unter Windows XP wird der entsprechende Schlüssel an anderer Stelle in der Registry gespeichert.
3. Du berücksichtigst vielleicht nicht, dass es bezüglich der Registry normalerweise auch eine Unterscheidung zwischen 32 und 64bit gibt, Stichwort "wow6432node"

Sollte es genügen Informationen über Betriebsystemversion und 32/64 bit Architektur zu erlangen ist Autoit in Kombination der bereits verwendeten DOS Befehle vielleicht auch noch eine Option. Du kannst per Autoit grundsätzlich auch DOS Befehle via run() aufrufen und sofern notwendig je nach Betriebssystem zuvor den richtigen Parameter (in deinem Fall Registry Pfad) ermitteln. Solch eine Mischform ist aber eher nicht zu empfehlen, wenn man auf die Rückgabewerte der externen Programme angewiesen ist. Eine saubere Lösung komplett in Autoit wäre jedenfalls vorzuziehen.

Zu guter Letzt:

Abseits von der Registry gibt es auch noch die Möglichkeit viele Anwendungen per API / COM Object zu steuern. Hierzu vielleicht mal schaun ob du eine Autoit UDF zu Outlook 2010 findest, für Excel und Word gibt es jedenfalls derartige Funktionssammlungen. Ob die allerdings mit der 2010er Version kompatibel sind weiß ich nicht.

Statt darauf zu hoffen, dass jemand versehentlich deine Daten löscht nach dem er den Stick "gefunden" hat würde ich an deiner Stelle von Anfang an verhindern, dass Daten lesbar sind ohne ein PW einzugeben. Ich persönlich würde jedenfalls niemals eine exe von einem fremden Stick ausserhalb einer geschützten Umgebung ausführen. Wenn würde ich vorher erstmal alles runterkopieren und es mir dann in Ruhe und ungestört ansehen, seltsam benannte exe Dateien kommen da wenn dann erst ganz zum Schluß dran.

Wie würde ich mich also vor Datenklau schützen?

Truecrypt Portable plus entsprechenden container, den ich erst mounten muss um an meine Daten ranzukommen. Hilft natürlich nicht wenn man den Rechner mit gemountetem Stick unbeaufsichtigt lässt. Aber bei Verlust/Diebstahl oder beim Abziehen des Sticks sind die Daten sicher vor fremden Zugriff.

EDIT: da war der "pinke" schneller

Dazu sollte erstmal klar sein, um was für ein sfx Archiv es sich handelt. Hier ging es wohl um die Konsolenvariante, man kann aber genausogut auch eine GUI Variante des sfx Archivs erzeugen. Zudem bietet die GUI Variante auch die Möglichkeit das pw und einen silent Parameter beim Aufruf zu übergeben (siehe WinRar Hilfedatei). Allerdings funktioniert bei mir die pw Übergabe per Parameter scheinbar nicht, pw angeblich falsch...

Gut ist ja nicht so tragisch, denn die GUI Variante erlaubt theoretisch ja auch die Nutzung von controlsend, was dann die normale pw Eingabe automatisieren würde.

Hab gerade keine Lust es zu testen, aber am einfachsten dürfte es wohl sein sich einfach mal den zu überprüfenden Inhalt in der Scite Console ausgeben zu lassen. Dann dürftest du auch sehen warum die stringinstr Prüfung vllt nicht mehr wie gewünscht funktioniert:

consolewrite('debug "WinDescription" : ' & @CRLF & $oVLCErrorHandler.WinDescription & @CRLF)

; If an error (the ActiveX control is not installed), then return False
if StringInStr($oVLCErrorHandler.WinDescription, "Unknown name") > 0 Then

GUICtrlDelete($oIEActiveX)
_IEQuit($oIE)
consolewrite("check returns FALSE..." & @crlf)
Return False
EndIf

consolewrite("check returns VLC Object..." & @crlf)
Return $vlc

Die einfachste Erklärung könnte ein Sprachproblem sein, vllt ist die Fehlermeldung bei dir ja auf deutsch. Es wäre aber durchaus auch denkbar, dass die ie.au3 nicht mehr richtig mit deiner IE Version zusammenarbeitet, soweit ich mich erinnere gab es da auch schon Probleme, weil die IE Funktionen nicht mehr ganz so frisch sind. Dazu kommen ggf. Sicherheitseinstellungen des Browsers, welche die Nutzung von activeX ohne Userzustimmung unterbinden könnten.