Beiträge von minx

Und die lauffähige Lösung ist oben, musst du nur noch übertragen. Das ganze Ge-Switche ist nicht nötig

zu der Global-Sache. Mit dem "sauber" ist das so eine Sache. Local ist in AutoIt immer das sauberste, denn Gloabl und erst Recht Dim können Errors verursachen. Das tun sie nicht oft, können sie aber. Also AutoIt Programmierer ist es sowieso notwendig zu wissen, dass ein externes Local ein Global ist.

Globals sind zu vermeiden
"Dim should not be used"

WhiteLion, so gehts :

Das soll ja nur für die Grundlagen sein. Vielleicht mache ich später mal ne Fortsetzung (Bau eines Voll-Addierers als Fortsetzung zu der Computer-Theorie).

1. Der OnEvent-Mode ist nicht "besser". Im Normalfall ist es besser den Message-Loop zu wählen, da die Aktualisierungsrate der GUI automatisch heruntergeregelt wird, wenn der Nutzer nichts tut

2. Global ist hier nicht nötig und sollte nicht benutzt werden. Ein "Local" außerhalb von Funktionen IST ein Global

3. In Zeile 27 switcht du die GUI Befehle auf die erste GUI. So gelten die nachfolgenden Befehle NICHT für die neue GUI ($Form4), sondern für die alte ($Form1)

Die 1.5.X ist raus. Bitte das ausführliche README beachten

(Anfängertutorial)

BitOR(6, 4) = 2 - aber was heißt das? Es ist mehr eine Geschichts-Stunde über: Frauen - und Mr. Booleans Mangel selbiger. Boolean lebte vor langer Zeit (wann genau interessiert eigentlich nicht). Er sah alle anderen Mathe-Genies der Zeit, wie sie "coole" neue Dinge entdeckten, zu Ruhm und Reichtum und damit auch ... Frauen kamen. Boolean dachte sich also: "Das will ich auch!" und begann zu forschen und zu theoretisieren. Der Hellste war er in diesem Gebiet nicht und stieß deswegen auch auf keine neue Formel oder ein neues Theorem. Also schmiss er alles übern Haufen und erschuf kurz und gut seine eigene Mathematik. Seine größten Forschungsergebnisse waren: Wahrheitstabellen! Hier ein Beispiel:

A = TRUE
B = FALSE


A AND B = B, weil nicht beide wahr sind, ist das Ergebis falsch, also B
A OR B = A, weil eines von beiden wahr ist, ist das Ergebnis auch wahr, also A
B OR B =B, nichts von beiden ist wahr, also ist das Ergebnis falsch, also B

Eigentlich ziemlich primitiv! Jeder dachte es wäre supergenial und innovativ, dabei hatte es absolut keinen Nutzen zu seiner Zeit. "Oh cool, A and B = A, wow!" Das war so ziemlich alles was man damit anfangen konnte, das Eis berechen auf Partys. Boolean brauchte sich aber nicht weiter um die Anwendung seiner Erfindung zu kümmern, denn er hatte bereits alles was er wollte und starb glücklich und zufrieden.

Wenn man es auf des Pudels Kern runterbricht, dann kann ein Computer nichts anderes als bool'sche Mathematik. Addition ist eigentlich nur komplexeres Vergleichen und alle anderen Rechenoperationen sind ebenfalls komplexere Additionen. Computer kennen nur zwei Zustände: 1 und 0, die WAHR und FALSCH darstellen. Hunderte Jahre nach seinem Tod erfährt Booleans Werk endlich einen Zweck ( ).

0 und 1 sind die zwei Zustände des binären Zahlensystems. Der Computer muss also alle Zahlen, die verglichen werden sollen ins binäre System umrechnen und dann jede Ziffer mit der korrespondierenden vergleichen (Bitwise). Binär? Beispiel:

13 binär = 1101 weil:


(2^3)(1) + (2^2)(1) + (2^1)(0) + (2^0)(1) = 13
(8)(1)   + (4)(1)   + (2)(0)   + (1)(1)   = 13
8        + 4        + 0        + 1        = 13


37 binär = 100101 weil:


(2^5)(1) + (2^4)(0) + (2^3)(0) + (2^2)(1) + (2^1)(0) + (2^0)(1) =37
(32)(1)  + (16)(0)  + (8)(0)   + (4)(1)   + (2)(0)   + (1)(1)   =37
32       + 0        + 0        + 4        + 0        +1         =37

In AutoIt sind wichtig: BitOR(), BitXOR() und BitAND().

x AND y : x UND y müssen beide WAHR sein, damit das Ergebis WAHR ist
x OR y  : ENTWEDER x ODER y muss WAHR sein, damit das Ergbenis WAHR ist. Es können auch 
BEIDE WAHR sein, damit die Aussage WAHR ist!
x XOR y : ENTWEDER x ODER y muss WAHR sein, damit das Ergbenis WAHR ist. Es dürfen 
nicht BEIDE WAHR sein, sonst ist die Aussage FALSCH!

So, mehr musst du nicht wissen. Wir können trotzdem nochmal 2 Beispiele durchgehen:

21 OR 9 = 29 
-------
1  or 0  = 1    Eins ist wahr -> wahr
0  or 1  = 1    Eins ist wahr -> wahr
1  or 0  = 1    Eins ist wahr -> wahr
0  or 0  = 0    Keins ist wahr -> falsch
1  or 1  = 1    Mindestens Eins ist wahr -> wahr


11101 ist binär für 29.


(2^4)(1) + (2^3)(1) + (2^2)(1) + (2^1)(0) + (2^0)(1) =29
(16)(1)  + (8)(1)   + (4)(1)   + (2)(0)   + (1)(1)   =29
16       + 8        + 4        + 0        +1         =29

108 = 1101100
14  = 0001110


108 XOR 14 = 98
---------------
1       0  = 1
1       0  = 1
0       0  = 0
1       1  = 0
1       1  = 0
0       1  = 1
0       0  = 0


1100010 ist binär für 98

Beispiele hier unten

Wenn er es mit AutoIt machen will, dann lass ihn doch machen, es ist nicht unmöglich und du weißt ja nicht was er noch vorhat

Das Deregistrieren ist mMn nicht wichtig, da das "objekt" keinen System-Namespace vereinnahmt. Wenn dich die paar KB im TempDir stören kannst du das auch wieder löschen (es wird ja nicht jedes Mal eine neue Datei erstellt, sondern immer die alte geleert + neu beschrieben).

Hi!

Ich habe mir mal ein neues Sprach-Paradigma für AutoIt erdacht, also eine neue Art, Skripte zu verfassen. Man könnte ganz primitiv sagen, Funktionen werden zu Objekten, aber es gibt doch signifikante Unterschiede zum Arbeiten mit normalen AutoIt Funktionen. Also wie geht das ganze?

Grundlage des Ganzen ist natürlich eine Funktion, meine UDF. Sie ist extrem kompakt und schmeißt doch den ganzen Sinn des BASIC-Paradigmas AutoIts über den Haufen. Die Idee dahinter ist, ein Modul als Objekt darzustellen. Nehmen wir als Beispiel mal eine 2D-Engine. Normalerweise würde man die so aufrufen:

$Handle = _Engine_Funktion(Par1, Par2, ..., ParN)
_Engine_Funktion2($Handle, Par1)

Nun ist das der UDF Standard, dem eigentlich jede AutoIt UDF folgt. Mit dem Object-CallBack-Functions-Global-Variables-Paradigm sieht das dann so aus (der Name lässt es vermuten):

$oEngine = _Engine_StartUp()
$oEngine.Function1(Par1, Par2, ..., ParN)
$oEngine.Function2(Par1)

So - was bringt einem dieses Objekt-Gehabe nun? Erstens sieht es meiner Meinung nach sauberer und besser aus und zweitens muss der Nutzer keine Variablen mehr von Hand durchreichen, da alle Variablen global deklariert sind, welche für die Engine wichtig sind! Der Nutzer muss sich damit also schonmal nicht mehr befassen.

Update: Ich hab das Ganze etwas umgeschrieben. Die Funktionen werden nun automatisch erkannt und in ein Objekt geschrieben. Dazu braucht es nur einen Funktionsaufruf, bei dem ihr keine Parameter übergeben müsst. Die Objekt-Funktionen werden jetzt mit __o_ als Präfix verfasst. Mehrere Objekte gleichzeitig sind jetzt möglich und es wird danach auch aufgeräumt ^^. Beispiel im Anhang. (dnke an BuFix für seinen Beitrag.

Falls noch Fragen bestehen (ich glaube schon ^^) einfach schreiben.

(Das ist optional! Es funktioniert mit der aktuellen Stable und muss nicht genutzt werden - wer darin "keinen Sinn" sieht, muss es nicht nutzen. Ich zitiere hier mal name22: "Ich denke das könnte sich noch als nützlich erweisen. Mir fällt kein expliziter Verwendungszweck ein, aber es ist auf jeden Fall ziemlich cool . ")

Und ich meinte: nach AutoIt

Ja klar. Beim Portieren von VisualBasic Programmen, bei denen die Structs TYPEn sind. Dort geht auch sowas:

TYPE Vector
    int x
    int y
    int z
END TYPE


TYPE ColorPoint
    Vector V
    int Color
END TYPE

Das ist leider (leider) in AutoIt nicht möglich. Dann muss man wieder auf Arrays aus Structs oder mehrdimensionale Arrays (höllen-langsam) zurückgreifen.

Bedenke: Keiner verbietet dir AO zu benutzen

Was jahrelang durch AutoIt-Object erprobt und begrüßt wurde und dann auf Drängen eines Devs endlich in AutoIt übernommen wurde soll nun einfach wieder wegfallen? Das ist sicher kein Fortschritt.

Structs und deren Objekt-Zugriff sind die Grundständigsten Elemente des BASIC-Paradigmas. Und was sich BASIC-Dialekt schimpft, sollte das auch berücksichtigen

My 2 Cent.

@Topic Ich hab nun wirklich fast alles durch und komme zum Schluss, dass es nicht möglich ist.

Laut Google AGB ist jeder Zugriff der nicht über die API oder direkt über das Webinterface erfolgt nicht erlaubt. Deswegen kommt bei Google früher oder später ein Captcha, wenn automatisch gesucht wird. Ich dazu nichts geschrieben, weil ich wusste, dass wieder darüber diskutiert wird .

4 Threads, 3 davon AGB Verstöße. Das wird nichts mehr...

Hast du schonmal dran gedacht eine Art "Wächter" zu machen, der die Skriptdateien überwacht und eventuelle Änderungen selbst einträgt? Hatte mal die Idee aber nie Zeit.

@Robin Bitte Code als Code posten. Erst auf , dann auf drücken und dann den Code einfügen

Ja, aber wo bleibt das normale Standard-Changelog als TXT Datei (Was in ein Projekt-Ordner kommt)? Siehe meine Posts (und die Links!) oben ^^. Spätestens beim Hosten eines Projekts, z.B. bei GitHub sind normale Changelogs das A&O (nach dem README).

Vielleicht sollte das etwas näher an lang erprobten "Standards" anlehnen :

YYYY-MM-DD  minx  <squarecode@web.de>


    * main.au3 (_SingleStringBetween() ): Errors eliminated 
    additional changes


    * myfile.ext (unrelated_change): my changes made
    to myfile.ext but completely unrelated to the above


    * anotherfile.ext (somefunction): more changes

Den Changelog aktuell halten und perfekt verfassen (von GNU, Autoren der mit meistbenutzten Lizenzen)
Mehr zu Changelogs und deren allgemeiner Formatierung

In deinem Beispiel fehlt noch die Zeile "print = ConsoleWrite" am Anfang.

Structs sind keine Klassen, auch wenn sie in machen Sprachen so benutzt werden. Ergo wird das hier nicht möglich sein:

This.That = ConsoleWrite

Die Multi-Inheritance (This.That.Those) wird nur von echten Objekten unterstützt. Ich hab damit auch schon nahezu alles versucht. Aber vielleicht findet noch jemand eine einfache Lösung