Beiträge von name22

Nö, Plugins sollten möglich sein. Das ist nicht ganz simpel, aber wenn du den AutoIt Interpreter in deine exe packst und eine kleine API aufbaust, die es ermöglicht bestimmte Werte im Hauptscript durch die, von mir angesprochene, Interprozess Kommunikation zumanipulieren, dann sollte das möglich sein. Es geht schon, aber je nachdem was für ein Funktionsumfang dir da vorschwebt beeinflusst das auch die Komplexität des Vorhabens.
Was müssen diese Plugins denn tun können?

Was genau soll das denn ermöglichen? Der User soll also sein eigenes Script schreiben können, dass dann in dein Script hineingeschrieben wird?
Was soll der User dadurch alles festlegen können? Es wäre gut wenn du mal den Zweck beschreiben könntest. Weil jetzt weiß ich immer noch genauso viel wie ich auch aus deinem ersten Post erahnen konnte ;).
Du könntest es ja mit einer Art Launcher versuchen. In dem Launcher wäre dann nur die GUI in der ein Script ausgewählt werden kann, und eine Funktion die dein Hauptscript und die Ergänzung des Users kombiniert, in eine Datei schreibt und ausführt. Allerdings kann man das nicht wirklich als "zur Laufzeit" bezeichnen...

Lass dir doch mal den Dateinamen ausgeben dann siehst du ja ob er korrekt ist.

Zitat

Christoph54 danke für den komplett sinnlosen und destruktiven Post..

Das geht doch auch freundlicher.
Die Funktion in deinem Link hat auch eine Menge einschränkungen, genau wie das Original. Sie bietet längst nicht die volle Funktionalität des AutoIt Interpreters und wird bestimmt auch nicht immer auf dem neuesten Stand sein.
Außerdem hat er Recht, ohne AutoIt auf dem PC wo das gemacht werden soll geht das nicht, egal in welcher Form. Ob du jetzt einen Interpreter selbst schreibst (was wohl meist weniger Sinnvoll ist), oder den AutoIt Interpreter in die kompilierte Datei mit einbindest und später wieder entpackst... Das man sich bei diesem Forum registrieren soll um da eine Datei runterzuladen von der ich keine Ahnung hab was drin sein könnte find ich auch nicht so prickelnd, daher werde ich das auch gar nicht erst ausprobieren.

@argon Du kannst, soweit ich weiß, nicht zur Laufzeit Funktionen in AutoIt Scripte einbinden. Aber du kannst den Code der ausgeführt werden soll in eine Datei schreiben und die per Kommandozeilenparameter an die AutoItv3.exe übergeben um sie sofort auszuführen. Wenn du allerdings Werte zwischen diesen separaten Prozessen übertragen willst, dann musst du dir ein Verfahren zur Interprozess Kommunikation aussuchen (z.B. TCP, Named Pipes, AutoIt Fenstertitel, Standard Input/Output Streams etc..).
In den meisten Fällen lässt sich das aber besser lösen, deshalb schließe ich mich mal Christoph an und frage: "Worum gehts denn speziell?" ;).

Für Beispiele gibts doch die Hilfe.

_Timer_SetTimer ;<-- Klick mal

Zitat

Was ist das überhaupt und wofür sind die denn gut :o?

http://msdn.microsoft.com/en-us/library/…v=vs.85%29.aspx
Wozu die WM_PAINT Message gut ist hab ich dir doch eigentlich in meinem Post erklärt?

Andere Programme zeichnen das Dargestellte neu ... Da kommst du nicht wirklich drum herum. Und schlimm ist das auch nicht.
Bei komplizierten Zeichenvorgängen kann man auch einen Backbuffer verwenden und den dann neu zeichnen, das ist effizienter.
Wie dem auch sei. Wenn du nicht willst, dass ein Teil des Bildes verloren geht, dann musst du eben auf die WM_PAINT Message reagieren die an alle Fenster gesendet wird die neu gezeichnet werden müssen (die Nachricht ist nämlich nicht nur Deko, alle standard Controls reagieren auch darauf und werden neu gezeichnet). Das geht folgendermaßen:

#include <WindowsConstants.au3>

GUIRegisterMsg($WM_PAINT, "WM_PAINT")

Func WM_PAINT()
;Hier alles neu zeichnen.
EndFunc

Edit:

Zitat

Kann man das anhalten des Scriptes verhindern? (Also wenn man das Fenster verschiebt?)

Nicht direkt, soweit ich weiß. Wenn du eine Funktion hast die, unabhängig vom Zustand des Fensters, regelmäßig aufgerufen werden soll, dann kannst du für solche Zwecke die _Timer Funktionen aus der Timers.au3 UDF verwenden um sie in einem angegebenen Intervall aufrufen zu lassen. Das passiert dann auch während man das Fenster verschiebt.

Das ist schon seltsam. Versuch es mal mit ein paar anderen Browsern, dann wissen wir ob hier nur der IE zicken macht.

Zitat

Ja, der depressive Roboter heißt Marvin (Wir bräuchten mehr Handtücher im Forum!).

Definitiv :D. Wir können ja passend zum nächsten Handtuchtag ein paar hier im Forum verteilen.

Zitat

Wie kann ich prüfen ob eine verbindung auf der ich "listen" noch aktiv ist ?

TCPSend setzt @error wenn der Socket geschlossen wurde. Und gibt die gesendete Datenmenge zurück (glaube ich).

Zitat

bzw kann ich verbindungen auf denen ich "listen" auch senden ?

Das hab ich jetzt nicht ganz verstanden... TCPListen erstellt einen Mainsocket der nur dazu dient eingehende Verbindungen anzunehmen, über den sendest du gar nichts (und empfängst natürlich auch nichts).

Herzlich Willkommen Marvin ;). Ich wünsch dir viel Spaß in unserem bescheidenen Forum.
Dein Avatar scheint allerdings längst nicht so sympathisch zu sein wie deine Vorstellung .

Zitat

Liegt das nun daran das er die Antwort von google's IP erwartet und von local host bekommt ?

Sollte es eigentlich nicht... Sonst würden Proxy Server nichtmit dem IE funktionieren.
In meinem Beispiel leite ich auch direkt die Antwort vom Server zum Clienten (FF, IE, etc.) weiter.
Es gibt aus meiner Sicht 2 Fehlerquellen: 1. Überprüfe mal ob alle Verbindungen zum Zeitpunkt des Versendens noch aktiv sind; 2. Lass dir mal die Requests und die Antwort des Servers ausgeben und schau nach ob sie auch vollständig sind.

Ich hab hier ein 32-bit und ein 64-bit System zu Verfügung. Falls du noch einen Tester brauchst stehe ich gerne zur Verfügung ;).
Das Projekt hört sich auf jeden Fall schon mal extrem nützlich an.

Auch wenn BugFix hier Moderator ist und seine Funktionen populär sind, heißt das nicht das jeder sie kennt der dir eventuell helfen könnte.
Und damit wir jetzt nicht alle seine Jahre alte Funktion rauskramen müssen wäre es nett wenn du hier nen Link zu seiner UDF oder praktischerweise auch die Funktion hier posten könntest.

Es könnte aber auch passieren, dass du Glück hast und BugFix auf deinen Thread stößt.

Oh, hab jetzt erst gelesen dass er keine Antwort empfängt. Das HTTP Request ist nicht valide... HTTP Requests enden immer mit einer Leerzeile (2 Zeilenumbrüchen), ansonsten weiß der Server nicht wann das Request aufhört und wartet für eine unbestimmte Zeit auf weitere Headereinträge.
Dann noch das was James angesprochen hat: Du sendest die Daten an den Socket der mit Google verbunden ist aber versuchst Daten von dem Socket zu empfangen der sich eigentlich mit deinem Clienten verbinden sollte (was er aus oben genannten Gründen sowieso nicht tut). Das sind 2 verschiedene Sockets und du verwendest den falschen, bzw. erwartest das Falsche ^^.
Schau dir doch mal ein paar Erklärungen und Standards des HTTP Protokolls an, ansonsten kommst du hier nicht weit. Und mein Beispiel funktioniert wie gesagt, eigentlich müsstest du das nur noch ausbauen...

Pack mal TCPAccept in eine Endlosschleife, die Funktion gibt lediglich -1 zurück wenn im Moment niemand versucht sich zu verbinden...
Eigentlich kannst du gleich mal 90 % meines Scripts übernehmen. Das wirst du nämlich für dein Vorhaben mindestens brauchen.

Ich hab mal einen kleinen Ansatz zusammengezimmert. Der ist aber natürlich noch längst nicht fertig oder gegen alle Fehler gewappnet, aber immerhin habe ich diesen Post darüber erstellt :P.
(Falls hier nur Müll drinsteht wundert euch also nicht, die Verbindung ist Schuld ...)

Zu viele Requests scheint dieses Script auch nicht zu mögen. Der Firefox ist da wohl ein wenig zu schnell...

Wenn man das aktualisiert flackert es zwar, aber der Rand ist weg.
Man kann aber auch einfach den Bereich begrenzen der aktualisiert wird, dann sieht es schon wesentlich besser aus und flackert nur bei sehr hohen aktualisierungsraten (20ms Intervall).

Bitteschön :

Edit: UEZ Das wusste ich ja gar nicht... Aber wenn man sich den Taskmanager anschaut sieht man es schon deutlich. Ich hab es mal hier auch hinzugefügt, aber eigentlich braucht man die Aktualisierung des Fensters ja dann auch gar nicht mehr.

Am besten ist es bei Kollisionschecks in Systemen begrenzter Präzision nicht nur den Ort eines Objekts sondern auch seinen Geschwindigkeitsvektor mit einzubeziehen.
Ich mache es lieber so, dass ich überprüfe ob die Strecke die sich aus Orts- und Bewegungsvektor des Objekts zusammensetzt die Strecke des Hindernisses schneidet (Bevor die Frame in der die Kollision sich abspielen würde generiert wird).
Beim Mauszeiger könnte man stattdessen den Vektor nehmen der von seiner vorherigen und seiner aktuellen Position beschrieben wird. Allerdings ist das auch eine potenztielle Fehlerquelle wenn man den Mauszeiger zu schnell über die Linie und wieder zurück bewegt.

Deswegen schaut man sich Beispiele und/oder die Beschreibungen von Funktionen in der UDF an.
Der zweite Parameter von OpenRequest ist nämlich: "$sObjectName - [optional] The name of the target resource of the specified HTTP verb."
Also der Pfad zum Zielobjekt. Wenn man sich mit dem HTTP Protokoll auskennt ist auch ersichtlich was man hier angeben muss.
Die entsprechenden Teile der URL die progandy beschrieben hat bekommst du, indem du die vollständige URL zum Ziel mit _WinHTTPSplitURL splittest.
Die domain gibst du dann bei Connect an und den restlichen Pfad hinter der Domain bei OpenRequest als Pfad zum Zielobjekt.
Und damit der Server keine Zeichen bekommt die nicht in einen URL encoded String gehören, musst du alle variablen Eingaben die solche Zeichen enthalten können per __WinHttpURLEncode encodieren. Aber das hat progandy ja schon alles geschrieben.
Ich formulier hier nur seinen Post ein wenig aus, was verstehst du denn an dem was er geschrieben hat nicht?