Beiträge von Andy

*senfdazugeb*
Genau wie das schon angesprochene Hintergrundrauschen der Soundkarte, kann auch das Rauschen von (abgedunkelten) Kamerasensoren benutzt werden, um Zufallszahlen zu erzeugen. Da dies ein zeitunabhängiger physikalischer Effekt ist, welcher nicht vorausgesagt werden kann, ist das schon ziemlich "zufällig". vgl. atomarer Zerfall.
Übrigens finde ich es interessant, daß bei Zufall automatisch von einer Normal/Gleichverteilung ausgegangen wird! Mal davon abgesehen, daß im Falle eines Zufalls der Zufall keinerlei Ahnung von Statistik hat, ist der Zahlenbereich bzw die Definitionsmenge für das zufällige Ereignis eigentlich nur 0 und 1.
Entweder ein Ereignis passiert, oder eben nicht. Das was wir nun Zufall nennen, ist nur die (beliebig erweiterbare) Folge von Nullen und Einsen, um einen größeren Wertebereich festzulegen.
Im Prinzip geht es um die statistische Wahrscheinlichkeit des Eintretens eines Ereignisses.
Die Zeit(dauer) erscheint uns nur nur deswegen zufällig, weil wir sicher wissen, daß man diesen Faktor (die vergangene Zeit) sicher nicht beeinflussen kann (in der Regel zumindest).
Gleichzeitig beeinflusst die Zeit aber alles andere in unserer Umgebung! Die Zeit beeinflusst gewissermassen alles! Daher bietet sich die Zeit als "Zufallsgenerator" an.
Chaostheorie^^
Wenn man nun davon ausgeht, daß "Zufall" nur eine beliebig (bzw. zufällig) große Folge von Nullen und Einsen ist, dann ist der Computer für die Ermittlung eines Zufalls prädestiniert, denn Nullen und Einsen sind sein Geschäft! Eigentlich muß man nur genügend Nullen und Einsen aus verschiedensten Quellen sammeln um dann irgendwann festzulegen, daß die gesammelte Menge reicht, um herauszufinden, ob mehr Nullen (Ereignis tritt nicht ein) , oder mehr Einsen (Ereignis tritt ein) vorliegen.
Ein schönes Beispiel wäre zzt. die Menge der in der letzten Sekunde von einem Internetknoten weitergeleiteten Datenpakete.

...oder per stringformat()

for $i=1 to 100
Consolewrite($i&" "&stringformat("als 3 Ziffern %03s\n", $i))
next

Habe das selbe Problem. AutoItscript startet Batchdatei. Die Batch kann ich nicht umgehen, da im Kontext der Batchprogramme die Codepage umgeschaltet werden muß. Danach wieder Umschalten auf die ursprüngliche Codepage.
Bisher habe ich auch noch keine andere Lösung gefunden, als die Ausgabe der Programme in der Batch statt in die Konsole mittels > in eine Datei umzuleiten, und dann diese Datei auszuwerten. Nicht sehr schön, aber funktioniert.

nein, das kommt von tuttifrutti
siehe quelltext
/edit/ ultralangsam....hatte auf autoberts post geantwortet

Wozu gibt es eigentlich eine Hilfedatei mit funktionierenden Beispielen zu Client/Server?
Dort gibts ein Clientscript und ein Serverscript, welche ohne Änderungen auf jedem Rechner im internen Netz lauffähig sein sollte.
Schritt für Schritt-Anleitung:
A) Beispielscript zu

TCPRecv()

(das ist der Server) zu einer EXE-Datei kompilieren und diese EXE starten! Ggf die Firewall anweisen, den Server zuzulassen oder ganz abschalten!
B) Beispielscript zu

TCPSend()

(das ist der Client) auf demselben Rechner starten.Text im Client eingeben, nach einem Enter sollte der eingegebene Text im Serverfenster erscheinen.
Wenn das NICHT so ist, dann ist entweder die Firewall das Problem (abschalten) oder die Netzwerkverbindung. Wenn I-net geht, ist das ein Layer-8-Problem, da hilft dann ab und zu, mehrmals heftigst den Kopf gegen die Türzarge zu schlagen, danach noch mal bei A) anfangen....

Sollte die Client/Serververbindung auf dem eigenen Rechner funktionieren, dann kann man anfangen im internen Netz zu testen. Ich gehe davon aus, daß eine funktionierende Netzwerkverbindung besteht, d.h. jeder der Rechner kann den anderen im Netz "sehen" und Daten austauschen.
Dazu die kompilierte SERVER.EXE auf einem anderen Rechner im internen Netzwerk starten, ggf Firewall deaktivieren.
Im Rahmen des Serverfensters erscheint eine IP-Adresse, z.B. 192.168.100.105.
Diese Adresse nun im CLIENT-Script (auf dem lokalen Rechner) in Zeile 18 eintragen:

Local $szIPADDRESS = "192.168.100.105"

und Script starten.
Sollte eine Fehlermeldung erscheinen....die Türzarge einige Male heftig mit dem Kopf, ihr wisst schon...das macht wach!
Falls keine Fehlermeldung erscheint, sondern der im Client eingegebene Text im Serverfenster erscheint, gehts weiter, Test im Internet.

Dazu ist es zunächst sinnvoll, sich bei einem der DNS-Service-Provider (z.B. DynDNS) eine kostenlose, "personalisierte URL" (z.B. Hoppelhase.dyndns.org) zu besorgen, unter der man dann auch bei wechselnder IP erreichbar ist. Das muss für die ersten Tests nicht unbedingt sein, erleichtert später aber vieles. Diese URL wird z.B. im Router eingetragen und dieser meldet eine vom Internetprovider neu vergebene IP an den DNS Provider. Wenn jetzt jemand eine Verbindung zu eurem Rechner aufbauen möchte, muß er nicht jeden Tag eine andere IP mitgeteilt bekommen, sondern merkt sich nur die URL Hoppelhase.dyndns.org. Diese wird bei einer (automatischen) Anfrage an einen Nameserver dann zu eurer zur Zeit aktuellen IP aufgelöst.

Weiter zum Thema Client/Server-Test im Internet:
Das kompilierte SERVER-Script auf dem lokalen Rechner starten. WICHTIG! Bei Verwendung eines Routers muß dem Router mitgeteilt werden, an welchen Server er die Datenpakete im internen Netz weiterleiten soll! Ist dem Router das Ziel unbekannt, so verwirft er die Daten einfach, und unser Server wartet ewig....
Damit der Router unseren Server "kennt", muß dieser mit (lokaler) IP und dem entsprechenden PORT in eine Liste eingetragen werden. Hat man so etwas noch nie gemacht, ist ein Blick ins Handbuch des Routers angesagt.In der Routerkonfiguration wird man u.U. bei "Port Forwarding" fündig und trägt dort die benötigten Daten ein. Bei meinem Router heißt der Menüpunkt für das forwarding "Firewall Rule".
ACHTUNG! Bei den meisten wird im Router ein DHCP-Serverdienst laufen, welcher den neu angemeldeten Rechnern im internen Netz eine mehr oder weniger zufällige IP-Adresse zuteilt! Daher sollte man, wenn man Serverdienste (HTTP/FTP/AutoIt-Server) im Internet bereistellt, dem Rechner, auf dem dieser Serverdienst läuft, eine FESTE IP-Adresse zuteilen. Ansonsten muß man u.U. täglich mehrmals seinen Router umkonfigurieren, damit dieser immer die aktuelle IP des Server-Rechners hat, und wer will das schon....
Für das "Port forwarding" gibt es jede Menge Anleitungen, falls es nicht klappt....Kopf....Türzarge....BÄÄÄÄM....das klärt den Blick!

Damit der Client sich mit dem Server verbinden kann, muss man die IP-Adresse des Servers (bzw. des Routers auf der Serverseite) herausfinden. Am einfachsten geht das, indem man VOM SERVER AUS eine Seite im Internet, wie z.B. https://autoit.de/www.wieistmeineip.de aufruft. Die dort angezeigte IP ist idR die IP, unter der der Router des Servers erreicht wird. Diese IP wird dann im CLIENT-Script in Zeile 18 eingetragen. Wie die dorthinkommt? Na per Email, SMS, Telefon, Briefpost, Aufschreiben und hintragen oder wie auch immer.....
Das ist der Grund für das Einrichten einer URL (Hoppelhase.dyndns.org) bei einem DNS-Service-Provider. Dann muss man ins Clientscript statt der ServerIP nur Hoppelhase.dyndns.org eintragen, und bei einer Verbindung wird (nach automatischer Anfrage an den DNS) die "richtige", d.h zzt. aktuelle IP des Routers auf der Serverseite genutzt.
Der Client muss den Router NICHT umkonfigurieren! In der Regel lässt ein Router alles von drinnen nach draussen durch! Eine Firewall blockiert auch (normalerweise) diesen Weg, daher im Zweifelsfall ausschalten.

Wenn nun Serverseitig richtig "geforwardet" ist, sämtliche IP-Adressen stimmen und die Türzarge endlich aus Kleinholz besteht, dann sendet auch der Client fleissig seine Daten ohne Probleme an den Server!
Wenn das alles funktioniert, DANN und erst DANN werden Scripte um/neu-geschrieben und auf eigene Bedürfnisse angepasst....und wenn die dann nicht funktionieren, dann liegt das nicht an der Technik, sondern am Unvermögen des Coders oder dessen Lernresistenz! In der Hilfe steht alles wichtige, weiterhin gibts massig funktionierende Scriptbeispiele. Somit gibt es keinen Grund mehr, "TCPIP funktioniert nicht"-Threads aufzumachen!

hihi, hab mein eigenes garnicht in der Aufstellung dabeigehabt. Das benutzt die DOS-Programme DIR und FIND und schlägt selbst Tweakys Script bzgl Geschwindigkeit.
Falls man öfter Dateien bzw Inhalte suchen sollte, bietet sich an, per Script alle paar Tage (Stunden) sämtliche Platten nach den vorhandenen Dateinamen zu scannen und diese Liste in eine Datei zu schreiben. Innerhalb dieser Liste ist eine gesuchte Datei dann wesentlich schneller gefunden, als über den Windows-Index(obwohl der genau das eigendlich machen sollte).

Hi, habe mal einige Funktionen zusammengetragen

Hab das gerade mal getestet, funktioniert einwandfrei mit Openoffice.
Tabelle erstellt und als pdf gespeichert.
Per AutoIt-Shellexecute das pdf öffnen, ctrl+a markiert die Tabelle im pdf, Daten mit ctrl-c in die Zwischenablage oder sonstwohin (textfile).
In OO-Calc per ctrl-v einfügen führt zur Abfrage nach Trennzeichen, dort "Leerzeichen" anklicken (lassen), fertig.
Allerdings werden die Textformatierungen (Fett usw) nicht mit aus dem PDF übernommen, ausschliesslich der reine (Tabellen)Text.

Hi,
beim Foxit Reader ist ein Textviewer dabei, der aus einer Tabelle einen Fließtext macht, ggf hilft dir das weiter.

/edit/ dieses VB-Macro gerade bei google gefunden, das an AutoIt anzupassen sollte ja mit der excel-udf nicht schwer sein

Option Explicit

Sub Versuch_SendKey()
'pdf-Programm:
Const strPdfProgNam As String = "C:\...\AcroRd32.exe"
'pdf-Datei:
Const strPdfNam As String = "G:\...\Datei.pdf"

If ActiveSheet.Cells(1, 1) <> "" Then
Exit Sub
End If

'pdf öffnen
Shell """" & strPdfProgNam & """ """ & strPdfNam & """", vbNormalFocus

'Zwischenablage:
SendKeys "^a", True
SendKeys "^c", True

'pdf Schließen:
SendKeys "%{F4}"

'In Excel-Tabellenblatt einfügen
ActiveSheet.Paste

End Sub

24 Postings und immer noch weiß niemand was der TE eigentlich machen möchte, eins hab ich aber verstanden:

Zitat

Z.b. auf dem Desktop mit dem namen test könnt ihr mir das schreiben.

Übersetzt: "Leg mir mal einer den Arm aus der Sonne...."
Falsches Forum würde ich sagen!
Ich bin dafür, solche Threads nicht nur zu schließen, sondern komplett zu löschen!

Hi,
ein Bekannter macht relativ viel mit Arduino, als großen Vorteil sieht er die Community und die schon fertigen Module, sehr praktisch für z.B. den Modellbau.
http://www.freeduino.de/books/arduino-tutorial-lady-ada
Bsp. Bauteile:
http://www.watterott.com/index.php?xc84a3=nskj289cm93g9pg7j1al42ph05&page=search&keywords=arduino&x=0&y=0

Beim Auswerten der "Laufzeiten" sollte man sich bei AutoIt keine großen Gedanken machen. Einige Zehntelsekunden bzw. sogar Sekunden mehr oder weniger bei den einzelnen Durchläufen sind völlig normal. AutoIt bietet auch keinerlei Möglichkeiten, diese Streuung zu vermeiden.
Festplattenaktivitäten im Hintergrund sind generell für die Ausführungsgeschwindigkeit von AutoIt-Scripten störend. Weiterhin bemerkt man deutlich bei Datenbewegungen, ob diese im Cache gelegen haben. Apropos Cache, beim Experimentieren mit dem Assemblercode habe ich Geschwindigkeitssteigerungen von Faktor 100 (ja, das heisst 100x schneller) beim identischen Rechenalgorithmus festgestellt. Wenn man das bei AutoIt "einstellen" könnte wie z.B. bei einigen C-Compilern und seinen Algorithmus auf die Hardware (z.B. Cache) anpasst, werden die in AutoIt "langsamen" Algorithmen (komprimierte Siebe z.B. Atkin) plötzlich x-mal schneller als die bisher schnellen, "normalen" Algorithmen.

Fazit: Zum schnellen "Rechnen" ist AutoIt nur sehr bedingt zu gebrauchen, da reißen auch schnell(st)e Algorithmen nichts raus! Wer Rechengeschwindigkeit braucht, setzt "richtige" Compiler ein und/oder schreibt damit eine per AutoIt verwendbare DLL!
Dann wird aus einem Mofafahrer(AutoIt) bei Verwendung von C(++) ein Hayabusa-Fahrer. Aber selbst darüber kann ein Jetpilot, der mit Mach2 (C mit Hardwareoptimierung, s. Link) durch die Atmosphäre brettert, nur müde lächeln
Schönes Beispiel: http://primzahlen.de/files/referent/kw/sieb.htm

oder so.....

Das funktioniert dann auch, wenn der Rechner zwischendurch runtergefahren bzw. neugestartet wurde

http://de.wikipedia.org/wiki/Header

Die Infos bekommt man da, wo man eigentlich alle Infos herbekommt^^ MSDN
z.B. http://msdn.microsoft.com/en-us/library/…ipboard_Formats

Aber diese Arbeit habe ich mir ehrlich gesagt nicht gemacht. Datei im Explorer markieren, ctrl+c.
Eine for/to Schleife und alle Rückgaben von _ClipBoard_GetData() ausgeben lassen und diese nach dem Dateinamen durchsuchen, voila, der Rest ist Stringmanipulation.

hm, seltsam, ich bekomme überall
\\rechnername\laufwerk\pfad\dateiname

@progandy
/EDIT/ Erledigt, hatte UTF versaubeutelt....manchmal sollte man nachts schlafen...dann kommt auch im Gehirn an, was das Auge sieht!....

veronesi
auf allen Freigaben im Netz bekomme ich den UNC-Pfad zurück. Wenn du auf der lokalen Maschine arbeitest, dann werden allerdings auch die lokalen Dateinamen zurückgegeben. Aber wo ist das Problem, die Rückgabe am Anfang auf \\ zu testen und dann den Servernamen davorzuhängen? Zu deinen Fragen:

- Ich habe mir jetzt nicht das Format angeschaut, aber der Dateipfad fängt erst ab dem 20. Zeichen (des Ursprungsstrings) an. Daher mit stringtrim() abschneiden.
- Strings werden allgemein üblich nullterminiert, d.h. das Nullbyte zeigt der anzeigenden Funktion (z.B. der Messagebox oder Consolewrite), daß der String hier zu Ende ist. Tatsächlich kann der string aber viel länger sein, er wird aber nur bis zum ersten Nullbyte dargestellt. Auch die AutoIt-Stringfunktionen juckt das Nullbyte irgendwo in der Mitte des Strings nicht, Ausnahme ist stringregexp(), aber wofür gibts stringtobinary()?^^

Den Dateinamen zu markieren wirst du mit ctrl+c hinbekommen. Dann per

$dateiname=Stringreplace(stringtrimleft(binarytostring(_ClipBoard_GetData(15)),20),chr(0),"")

auslesen. Klappt unter XP32, bitte mal unter anderen BS testen...

Wenn das Patchen der EXE kein Problem ist, wieso machst du dann kein Auswahlmenü rein?
Das sind nur einige Zeilen Code, die du an das Ende der EXE anhängen müsstest, 1x Sprungadressen umbiegen, fertig. Seit es dieses Dateiformat gibt, wird das so gemacht....
Mal abgesehen von der schon von Pee angesprochenen Sinnhaftigkeit eine EXE zu patchen (was glaubst du wie lange die Spielehersteller das erlauben werden?) ist das Thema "AutoIt" hier völlig aussen vor. Vote for close....

Ja,
du kannst natürlich Texte in einer ausführbaren Datei ändern, das ist auch mit AutoIt überhaupt kein Problem.
Das Problem, die Texte in der EXE direkt zu ändern besteht darin, daß du nur mit gleich langen oder kürzeren Texten ersetzen kannst. Bei z.B. Pfaden sollte man das beachten!
Ob du den Pfad im Ram änderst oder direkt in der Datei, bleibt gleich. Datei ändern ist wesentlich einfacher.
Das ändern im Ram ist dann genauso einfach möglich, wenn du die Einsprungpunkte (Adressen) kennst. Um mehr zu erfahren, solltest du dich mit dem PE-Format (http://www.microsoft.com/whdc/system/pl…are/PECOFF.mspx) auseinandersetzen. Dort ist das Format erklärt, für eine Anwendung in AutoIt solltest du im engl. Forum nach "Subrogation" suchen.

Ich verstehe nicht was du mit Nomad vorhast, die 08/15 Stringbefehle von Autoit reichen doch vollkommen aus um deinen gesuchten String im Ram zu finden und abzuändern?