Beiträge von Andy

**Andy**

Zitat

Verstehe das Problem nicht...

Ich schon^^
Übersetzt bedeutet das "Wenn hier jemand ein Desktopbereinigungsprogramm hat oder für mich schreibt, dann freue ich mich, ansonsten ist mir das zuviel Arbeit und ich mach die dafür erforderlichen 3-4 Mausklicks lieber von Hand!"

**Andy**

Zitat

Ich muss mir mal die Funktion StringRegExp() rein ziehen. Scheint richtig mächtig zu sein!

So gehts mir seit Jahren^^.
Aber da ich (in den meisten Fällen) mit den "normalen" Stringbefehlen zum Ziel komme und das in einer für mich "nachvollziehbaren" Form, fristet diese mächtige Funktion LEIDER nur ein Schattendasein. Wahrscheinlich fehlt wie bei den meisten anderen Anwendungen (Datenbank, Grafik, TCP) das "richtige Problem". Wenn man gezwungen ist, sich bis zum Hals reinzuknien, dann sinkt die Hemmschwelle rapide und man bekommt schnell den Einstieg...

**Andy**

Dann wärs ja schön wen du andere auch daran teilhaben lassen würdest dass DU es hast....

**Andy**

schau dir mal den AutoIt-Befehl

[autoit]

#include

[/autoit]

an. Eine UDF ist ein ganz normales AutoIt-Script, du könntest es auch zur Not einfach unter dein vorhandenes Script drunterkopieren

**Andy**

Zitat

danke für den Vorschlag, es sollen aber eigene "Befehle" erstellt werden können.

Ah, ok, dann kannst du aber wenigstens die "Abfrage" der Wortanfänge/Wörter aus dem Beispiel nutzen^^

**Andy**

Zitat

mein problem ist das der thread immer schon nach unten geschoben wird

Meins nicht, da ich mir sowieso nur die "Bearbeitet in den letzten 24 Stunden "-Threads anschaue, und da wird deiner auch beachtet wenn er auf Position 26 steht!

**Andy**

Zitat

Das mit @Crlf funktioniert auch bei textdateien oder?

Ja^^
CR Carriage Return= Wagenrücklauf (von der Schreibmaschine noch)
LF Line Feed = Zeilenvorschub (auch von der Schreibmaschine)

Es gibt auch Texte, die nur mit LF arbeiten

**Andy**

Das Script in der Hilfe zu _WinAPI_CallNextHookEx() ist ein Beispiel, , da noch ne handvoll Zeilen dazu und fertig.

**Andy**

Hi,
eine fertige Funktion nicht, aber wo ist das Problem? Die entsprechenden Scite-Files einlesen, und per stringregexp() nach den ersten eingetippten Buchstaben filtern.
Das sollte auch von der Geschwindigkeitkein Thema sein, sind ja nicht viele Befehle.

**Andy**

/EDIT/ ...alles gelöscht, der CLIENT braucht NIE eine Weiterleitung, ggf aber eine Freigabe der Firewall...

**Andy**

Zitat

aber wenn man in "ByteSprache" etwas schreibt, wie kann man daraus die anderen Sprachen entwickeln?

Mal angenommen, ich möchte folgenden Text "Hallo, hier ist ein Text" auf einem Rechner mit einem x86 Prozessor ausgeben. Der Prozessor verarbeitet nur Nullen und Einsen in Form von Bits und Bytes, Register müssen geladen werden, bestimmte Prozessorflags gesetzt, Speicher muss beschrieben werden .....
Für die "einfachste" Prozessorsprache nehmen wir das Beispiel Assembler, welcher einfache Befehle (fast 1 zu 1) in ausführbaren Bytecode übersetzt. Mal angenommen, ich habe folgenden Assemblercode,

Code

Text db 'Hallo, hier ist ein Text'  ;schreibe einen Text in den Speicher an eine bestimmte Adresse
mov  dx,offset Text       ;lade die Speicheradresse von Text in das Register DX
mov  ah,09                ;lade die Hexzahl 09 ins Highbyte vom Register AX (Zeichenkette darstellen)
int  21h           ;löse den Prozessorinterrupt 21h aus

dann wird mit diesem Code ein bestimmter Text ausgegeben. Wie du unter diesem Link nachlesen kannst, existieren allein für den int21 über 100 Funktionsaufrufe. Allerdings gibt es noch viele andere Interrupts um Daten innerhalb des Speichers und der Prozessorregister hin- und herzuschieben, mal abgesehen von den hunderten Prozessorbefehlen
Wenn du nun dieses "Programm" in Maschinensprache umwandelst (das macht der Assembler), dann sieht es für einen x86 Prozessor so aus:
0xBA0D01B409CD21EB00B44CCD2148616C6C6F2C20646173206973742065696E20546578742E24

Du kannst dieses "Programm" laufen lassen indem du es in eine Datei schreibst und diese Datei dann aufrufst.
Allerdings muss man dazu eine DOS-Box öffnen und den Dateinamen eintippen (nix für Mausschubser^^ )
Aber auch AutoIt kann Dateien schreiben, also nehmen wir unseren Bytecode uns schreiben ihn in eine Datei namens Demo.COM

[autoit]

$handle=fileopen(@scriptdir&"\demo.com",18)
filewrite ($handle,"0xBA0D01B409CD21EB00B44CCD2148616C6C6F2C20646173206973742065696E20546578742E24")
fileclose($handle)

[/autoit][autoit][/autoit][autoit]

RunWait("cmd.exe",@scriptdir) ;eine Dos-Box öffnet sich, DEMO eintippen und Enter drücken

[/autoit]

Dieser Code läuft nur auf x86 Prozessoren in einem bestimmten Modus. In dieser Form wird er auf anderen Prozessoren nicht laufen....
Wenn du diesen Code auf einem Apple-Rechner laufen lassen wolltest, oder auf deinem Handy oder in der Küchenuhr, dann müsste der Code immer auf den jeweilig in diesen Geräten vorhandenen Prozessor abgestimmt sein!

Und um nicht für alle diese Prozessoren immer wieder bestehenden Code anzupassen, wird für jeden Prozessor ein Compiler geschrieben, der den komplizierten Vorgang "Schreibe Text" in die jeweilige Prozessorsprache übersetzt. In AutoIt heisst der Befehl "Schreibe Text" nun consolewrite(), in C heisst der Befehl printf() , in Basic Print() uswusf.
Der C-"Compiler" für einen x86-Prozessor macht nun aus der Zeile printf("Hallo, hier ist ein Text"); das schon bekannte 0xBA0D01B409CD21EB00B44CCD2148616C6C6F2C20646173206973742065696E20546578742E24
welches der Prozessor "verstehen" kann.
Auf einem Applerechner lautet der Maschinencode sicher anders. Allerdings ist die Ausgabe "Hallo, hier ist ein Text" völlig identisch! Und genau das ist der Sinn und Zweck einer (höheren) Programmiersprache wie C, Basic, Fortran, Cobol usw., möglichst auf vielen Prozessoren denselben möglichst identischen Programmcode benutzen zu können! Da C ziemlich verbreitet ist, wird heutzutage kein Microprozessor mehr entwickelt, ohne gleichzeitig den dazu passenden Compiler bereitzustellen!

**Andy**

Zitat

Genau den Punkt verstehe ich nicht.
Schließlich gibt es diesen Übersetzer ja schon (der Interpreter).
Wieso muss zwingend zur Laufzeit interpretiert werden? Wieso nicht (einmalig) davor?

Weil das "zur Laufzeit interpretieren" relativ einfach ist. Du musst nur den Code analysieren und dann das was dort steht per (in diesem Fall C) eigenem Befehl ausführen. Im Prinzip könntest du einen C-Interpreter in AutoIt schreiben.

[autoit]

#include <String.au3>
$zeile_C=' printf("Fehler: Datei nicht gefunden.");' ;eine Zeile C-Code

[/autoit][autoit][/autoit][autoit]

if stringinstr($zeile_C,"printf") then
$a=_stringbetween($zeile_C,"printf(""",""");")
consolewrite($a[0])
endif

[/autoit]

So, jetzt schreib das mal so in Maschinesprache, daß es ausführbar in eine Datei geschrieben werden kann....wie gesagt nicht "interpretiert" sondern in reiner Maschinensprache! Ich hab mir mal die Mühe gemacht^^. Damit man mal sieht wie kurz ein Programm in Maschinensprache sein kann (43 Byte abzüglich 21 Byte Text^^) , als *.COM-Datei am besten auszuführen auszuführen in einer DOS-Box.
Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist. ich musste die Datei zippen, weil *.COM Dateien nicht hochgeladen werden dürfen^^

**Andy**

Jaein, den "Socket" bekommst du als Client idr. nicht vom Server, sondern von deinem Betriebssystem. Der Socket ist eine Schnittstelle für die Kommunikation.

Zitat

Nun stelle ich mir die Frage ob ich die SocketID von einem Programm heraus finden kann das schon mit dem Server verbunden ist.

Wozu? Der Server erstellt auf Anfrage einen neuen Socket, der dann mit dem von dir (z.B. dem AutoIt-Client) erstellten Socket kommuniziert.

Wenn dein Firefox schon mit einem Server verbunden ist (eingeloggt), wozu willst du dich dann in diese Verbindung "einklinken" obwohl du bereits verbunden bist?

**Andy**

Ok, um das mal ein bisschen weiter auszuführen...
Die einzige "Sprache" die ein Prozessor direkt versteht ist die Maschinensprache. Da es aber relativ mühselig und unübersichtlich ist in Maschinensprache (Assembler) zu programmieren und auch jeder Prozessor andere Maschinensprachebefehle hat, wurden die sogenannten "Hochsprachen" erfunden.
Das heisst, irgendwann hatte ein Programmierer die Nase voll von reihenweise Stack-gefummel, Bitschieberei und Speicheradressenabzählerei in Maschinensprache und wollte gleichzeitig auch noch ein Programm, welches mit identischem Code auf verschiedenen Prozessoren lauffähig war.
Er wollte Code haben, der auch von Nichtprofis relativ leicht lesbar und einfach änderbar war. Nun musste dieser Code aber in die Maschinensprache übersetzt werden, damit der Prozessor überhaupt etwas damit anfangen konnte. Nun gibt es zwei Möglichkeiten:

1). Der "Übersetzer" liest das Hochsprachenprogramm ein, analysiert es komplett und übersetzt es ein fix- und fertiges Maschinespracheprogramm. Das hört sich simpel an, tatsächlich war diese Prozedur (und ist nach 40 Jahren m.E. eher schlimmer als besser geworden) ein aufwändiges Unterfangen.
Der sogenannte Compiler wandelt also einen Hochsprachenquelltext (C,Basic, Fortran uswusf..) in ein eigenständig lauffähiges Maschinespracheprogramm (*.EXE oder *.COM-Datei) um, welches man NICHT in eine Hochsprache (ausser in Assembler) zurückverwandeln konnte. Der Quellcode ist nicht auf Anhieb nachvollziehbar.

2.) Da ein "einfaches" compilieren schon relativ aufwendig war (lange Laufzeiten des Compilers und Linkers) wurde oft eine andere (einfachere) Variante bevorzugt. Der Interpreter hat den Quellcode abgearbeitet und zur Laufzeit die Befehle analysiert und ausgeführt. Das hat zwar von der Ausführungsgeschwindigkeit etwas länger gedauert, dafür konnte man sofort (ohne den langwierigen Compilerlauf) mit dem Programm loslegen und auch das debugging vereinfachte sich enorm. Nachteil: für jedes Programm im Quellcode war auch zwingend der Interpreter (also mindestens zwei Dateien) notwendig. Weiterhin war der Quellcode von jedem einsehbar.

Mittlerweile gibt es reihenweise Zwischenlösungen, etwa Java und teilweise auch .Net, welche in einen "Pseudocode" übersetzt werden. Der Vorteil liegt auf der Hand, egal welche Prozessorarchitektur verwendet wird, wenn es für diesen Prozessor einen Pseudocode in Maschinesprache-Übersetzer gibt, dann ist das Programm auf diesem Prozessor lauffähig.(Soweit die Theorie )

AutoIt ist eine der cleveren Lösungen! Das "compilieren" dort macht aus dem Quellcode keine Maschinesprache, sondern packt nun einen Interpreter und den etwas aufbereiteten Quellcode zusammen in eine Datei! Wenn man also eine per AutoIt "compilierte" EXE startet, dann startet der darin enthaltene Interpreter und führt den ebenfalls in dieser Datei enthaltenen Quellcode aus.

Zitat

gibts dann Möglichkeiten das Skript trotzdem in ein C++ format zu bringen?

schreib "einfach" einen AutoIt2C-Konverter, und du wirst viele Freunde haben^^.
Es gibt schon reihenweise solcher Konverter von einer Hochsprache in eine andere, einer der bekannteren ist z.B. BCX

Zitat

Wieso greift man diesen output nicht ab? Autoit ist doch deshalb so "langsam" weil das Skript zur Laufzeit interpretiert werden muss.

Die einzige Alternative wäre ein "richtiger" Compiler, welcher direkt den AutoIt-Code in Maschinensprache transferiert. Ob dieses Projekt irgendwann angegangen wird, wage ich zu bezweifeln. Mehrere hunderte Mannjahre (unbezahlte) Entwicklung in ein Projekt zu stecken damit vielleicht ein Promille der Anwender ein "schnelleres" Script haben, halte ich für überflüssig. Wer mit aller Gewalt ein SCHNELLES Programm braucht kann (soll) sich auf dem Markt an einem der vielen Compiler orientieren oder die benötigten "schnellen" Funktionen in AutoIt per Assembler ausführen. Das nötige Knowhow natürlich vorausgesetzt

**Andy**

Zitat

Hab mich durch die 4 Tutorials gearbeitet aber kapiers noch immer nicht.

Es gibt auch eine (deutsche) Hilfedatei mit Beispiel-Scripten zu fast jedem AutoIt-Befehl. Wenn man dort etwas bzgl Maus sucht, wäre eine Suche mit *mouse* ziemlich erfolgreich...

**Andy**

Hi,
die *.EXE ist bereits das "Windowsstandardisierte Format". In der Exe steht der ausführbare, für den Prozessor lesbare Code, welcher normalerweise von einem Compiler erzeugt wird.
Bei AutoIt kommt noch etwas anderes hinzu. In der von AutoIt "compilierten" Exe steht nicht ein "richtiges" Kompilat des Scriptes in Maschinensprache, sondern grob gesagt ein Interpreter mit angehängtem Orginalscript.
D.h. beim Start der *.EXE wird der Interpreter geladen, dieser lädt wiederum das "Script" und arbeitet es ab....
Daher ist/war es möglich den Scriptcode aus der EXE herauszubekommen, was bei "richtigen" Compilern nicht funktioniert.

**Andy**

/*EDIT*/ gelöscht, weil Vorschau nicht genutzt.....

**Andy**

Zitat

ob jemand zu einem derartigen post verlinken oder dasmal zusammenfassen kann.

Siehe Link im 1. Post und Stilgars Umsetzung hier

**Andy**

Hallo,
wenn ich das jetzt richtig verstanden habe, dann möchtest du einen mehr oder weniger komplett ausgefüllten Lottoschein überprüfen?!

Dann könntest du die GUI so erweitern, daß du dem Spieler mehrere Auswahlmöglichkeiten gibst.
a) den Lottoschein ausfüllen (mittels Zahlenfeld) und die augefüllten Felder in eine INI schreiben.
b) automatische Auswertung, d.h.Vergleich der downgeloadeten Lottozahlen mit den Zahlen in der INI mit Anzeige der "Richtigen"

Btw. ich habe sogar ein AutoIt-Script, welches das automatische Auswerten der eingescannten ausgefüllten Lottoscheine erlauben würde! Allso den ausgefüllten Lottoschein einscannen, "Auswerten" drücken und tadaaaa, eine Sekunde später hat man die "Richtigen" in Textform, anschließendes Schreiben in eine Datenbank inclusive! Bei ernsthaftem Interesse bitte PM an mich....

Beispiel:

Spoiler anzeigen

[autoit]

#include <EditConstants.au3>
#include <WindowsConstants.au3>
#include <Array.au3>
#include <ButtonConstants.au3>
#include <GUIConstantsEx.au3>
#include <Inet.au3>
#include <String.au3>
$body = _INetGetSource("http://www.lotto.de/gewinnzahlen_und_quoten.html")