Beiträge von Andy

Zitat

Die Sache wäre wohl eleganter, wenn man einen schlichten Sprungbefehl hätte ("GOTO").
Leider haben wir den nicht - und der Stack ist begrenzt. Deshalb gefällt mir die Idee nicht.

Das "GOTO" bringt dir nicht wirklich etwas, denn den Stack musst du so oder so "bereinigen". Solange nur die Rücksprungadressen auf dem Stack liegen und etwaige Variablen innerhalb der (dann sehr einfachen) Funktion benutzt werden, würde ein "GOTO" in der untersten Rekursionsebene gefolgt von einem "Schieb den Stackpointer XXXX Bytes nach oben, um den Speicher freizugeben" die Rekursion beenden.
Wenn du allerdings, und das kommt in diversen rekursiv aufgerufenen Funktionen häufig vor, das Ergebnis des Funktionsaufrufs innerhalb der Funktion (nach deren Rückkehr) weiterverarbeitest, bringt das GOTO nichts! Denn dann muss die Rekursion komplett vonn innen nach aussen abgearbeitet werden, Stichwort rekursive Dateisuche über alle Verzeichnisse.

*OT on*

Zitat von peethebee

Goto-Code ist einfach undebugbar

Da sage ich nur:"Beschissen dokumentierter Code ist undebugbar!", völlig unabhängig davon, ob nur ein einziges GOTO verwendet wurde!

Ich weiss nicht, wieso Gott und die Welt was gegen GOTO haben, ich habe weder mit den ersten BASIC-Dialekten noch mit meinem BASIC-programmierbaren Taschenrechner noch bei Batch-Dateien irgendwelche Probleme (damit gehabt). Es ist ein Sprungbefehl wie so viele andere auch, btw. kenne ich keinen einzigen Prozessor, der etwas anderes als ein GOTO (in Form eines Sprungbefehls) verwendet, wobei man fairerweise sagen muss, dass es auch etwas ähnliches wie do/loop gibt, langsamer allerdings

Wenn AutoIt ein GOTO hätte, wäre es dann eine "schlechtere" Programmiersprache?
*OT off*

Hi,
wie AspirinJunkie schon erklärt hat, bieten sich bei manchen Problemen iterative Lösungen an, oder auch rekursive, oder auch beide. Rekursionen bieten sich z.B. an, wenn man Code sparen möchte, das geht dann aus den angesprochenen Gründen (Stack, Verwaltung usw) auf kosten der Geschwindigkeit.

Ein schöner Thread zum Thema findet sich hier.

Zitat von ohforf

Also mir gefällt die Idee überhaupt nicht.

Kann ich nachvollziehen, du hast nämlich garkeine rekursive Funktion erstellt, sondern einen endlos-Speicherfüller! Eine rekursive Funktion enthält nämlich ein Rückkehr-Kriterium, irgendwie muss ja abgefragt werden, wann die Funktion zu ihrem Aufrufer zurückkehren soll...

foo()

Func foo()
if abbruchkriterium then return
foo()
EndFunc ;==>foo

Um mal eine kleine Anekdote zum Besten zu geben (man beachte meinen Forentitel^^):
1980 war ich in der 9. Klasse, damals hatte ich einen Mitschüler, der mit einer Ampelsteuerung für eine grosse Kreuzung in München (7 Zufahrten) einen Preis bei "Jugend forscht" gewonnen hat! Er hatte tatsächlich aus vielen kleinen Lämpchen ein funktionierendes Modell gebaut.
Übrigens wurde diese Steuerung tatsächlich installiert, so dass in der Hauptverkehrszeit 10% mehr Autos pro Ampelperiode über die Kreuzung kamen als vorher!

Zitat

In der neuesten Funktion wurde dieses umstrittenen UDF entfernt

1. heisst es "neueste Version", und 2. wen interessiert das?
Wenn die Funktion funktioniert, häng sie unten an dein Script und verwende sie!
Nur weil irgendeine Funktion von irgendwem am anderen Ende der Welt in seinem Programmpaket nicht mehr mitgegeben wurde (aus welchen Gründen auch immer), heisst das doch lange nicht, dass ich diese Funktion nicht in meinen Programmen verwenden kann.
Wenn die Entwickler in der nächsten AutoIt-Release beschliessen, GARKEINE UDF´s mehr mitzugeben, ändert sich doch auch nichts! Oder glaubst du, dass mich irgendein Mensch daran hindern kann, mir bekannte Funktionen weiter zu verwenden?

habe mir angewöhnt, wenn möglich sowieso alle structs "am Stück" hintereinander in einen zusammenhängenden Speicherblock zu schreiben. Der wird dann einmal an einer 16-byte-Grenze aligned und dann kann man nach belieben damit arbeiten. Im Debugger sind das mittlerweile fast 2k an struct, Da kommts dann auf das bisschen 65 Bytes auch nicht mehr an

Was soll ich sagen, ULTRACREMIG! Vielen Dank, funktioniert einwandfrei. Den Button hänge ich jetzt noch irgendwie an die GUI, damit er sich ggf. mitverschiebt, aber das sollte jetzt nicht mehr so wild werden!
Meine dll hab ich auf 96 Byte eingestampft, incl der Ressourcen natürlich^^, allerdings wird das wiederum aufgefressen von der Orgie, das Ding in den Speicher zu entpacken, dort zu starten, registrieren uswusf, in AutoIt nicht wirklich "schön"...

Dein Button macht das Rennen! Änderungen an Grösse, Style usw sind so auch einfacher nachvollziehbar wie Änderungen in einer geladenen dll....

Zitat

aber dafür musst du die ganzen Strukturen von Hand zusammenbasteln

hehe, da bin ich auch schon durch, da ist die dll mit den Ressourcen schneller und einfacher zu basteln.

Zitat

Oder du hängst di Dialog-Ressourcen an die AutoIt-Exe an, aber dann musst du immer erst kompilieren.

genau das wollte ich vermeiden, es geht um einen "Debugger" für den inline-asm-code (AssembleIt), der zur LAUFZEIT des Assemblercodes Daten an eine AutoIt-GUI ausgibt. Da ist permanentes kompilieren Kontraproduktiv imho.

Zzt. bin ich so weit, den kompletten "Debugger" (eigentlich ist es nur ein Anzeigefenster für alle Registerinhalte, Prozessorflags, FPU- und SSE-Registerinhalte, Inhalte des Stacks usw.) in Autoit in das AssembleIt-tool eingebunden zu haben. Nur das "weiterschalten" der GUI geschieht zzt. noch über das modale MsgBox-Fenster.

Aktueller Stand ist so, dass zwischen die einzelnen Assemblerbefehle ein _ASM_DEBUG() eingefügt werden kann, welches dann während der Laufzeit die GUI für die Anzeige der Daten aufruft. Weiterhin kann damit auch ein Abbruchbefehl z.B. in einer ASM-Schleife eingefügt werden. _ASM_DEBUG("eax<50") lässt dann den Assemblercode so lange laufen, bis das Register eax einen Wert kleiner 50 enthält. Also schon sehr komfortabel.

Ob man für "Weiter" nun auf den "OK"-button der MsgBox klickt oder auf einen Button innerhalb der GUI ist eher Kosmetik, aber du kennst das ja, für die 5% verbesserte Usability werden 95% Gehirnschmalz und Arbeit aufgewendet^^

Hi,
du unterscheidest die Clients je nach Verbindung (socket) mit dem Server. Da der Server ja permanent auf neue Verbindungsanfagen durch die Clients wartet, kannst du diese z.B. in einem Array speichern.
Ich habe ein Script, bei welchem verschiedene Clients über den Server Daten austauschen, allerdings nur 5 bis 8 Clients. Wie das bei 60 gleichzeitig verbundenen Clients aussieht, musst du einfach ausprobieren.

Zitat

Ist aber wirklich seltsam, dass eine msgbox das Problem umgehen kann.

Nein, das ist garnicht seltsam, das hängt damit zusammen, dass MsgBox die API-Funktion DialogBox() aufruft, welche eine eigene Message loop installiert. Und die wiederum "fängt" sich die Messages.

Prog@ndy, vielen Dank, da habe ich ja was zu tun^^
Da der asm-Code Threadsicher ist, könnte ich ihn in eigene Threads verfrachten, mal schauen, was passiert.
Im Zweifelsfall mache ich doch eine "eingebettete" dll, das Problem von DialogBox() ist eigentlich nur, dass es die Fensterdaten aus den Ressourcen einer Datei ausliest. Eine asm-dll habe ich mittlerweile auf einige Bytes zusammengestampft, da die Ressourcen reingepackt und fertig wäre die Laube. Ich hatte schon das komplette Fenster als modale GUI getestet, das funktioniert auch, baut das Fenster aber in jedem Durchlauf "neu" auf, auch suboptimal....

Hi,
vielen Dank, aber ich glaube, du hattest es etwas falsch verstanden^^
Ich benötige die Endlosschleife innerhalb der Funktion _CB(), gewissermassen an Stelle der Messagebox!
Die Messagebox hält das Script innerhalb der _CB() an, ohne dass es zu einer "Keine Rückmeldung"-Nachricht an die GUI kommt.
Die Messagebox soll nun durch eine Endlosschleife ersetzt werden, so dass es nicht zur "Keine Rückmeldung"-Nachricht an die GUI kommt.

Ich möchte ein "warte auf Mausklick auf den WEITER (in der MsgBox ist das der OK) -Button" realisieren.
Letztendlich soll in der _CB() eine Endlos-Schleife laufen, welche durch einen Klick auf den Button beendet wird. Per globalem Flag zum Beispiel.
Ein kleines Fensterchen, welche die Funktion der Messagebox übernimmt an der Position des Buttons würde mir auch schon reichen!

Ich habe schon eine dll erstellt, die aber nichts weiter als ein "echtes" modales Fenster (nur mit OK-Button) an der Position des "Weiter"-Buttons erstellt. Aber ich möchte diese dll nicht in den Code einbinden und daraus starten bzw. als externe Datei mitgeben, da sie im Vergleich zum restlichen AutoIt-Code immens gross ist....90kB um ein kleines Fensterchen mit einem OK-Button irgendwo auf eine GUI zu pinnen ist ziemlich happig!

heyho,
ich hab mich mal an den Landschaften versucht^^
Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.
Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.
links das von marsis Script erstellte Höhenprofil, rechts die Landschaft dazu^^

Dazu in Marsis Script folgendes eintragen

weiterhin ab Zeile 144 folgende 3 Zeilen einfügen:

danach dann folgendes Script starten (lädt die Bitmap als Höhenprofil und zeichnet die Landschaft)

das ist "native" AutoIt, da sollten wir wesentlich mehr rausholen können^^

Habe mal ein Beispielscript angehängt, einfach starten, so läuft es einwandfrei(32Bit).
Während der Anzeige der Messagebox kann auch der Button in der GUI angeklickt werden.

Wenn aber in der Callback-Funktion _CB() die while/wend einkommentiert wird, kommt nach einigen Sekunden Sanduhr die "keine Rückmeldung"-Msg in der GUI.

Es dauert etwas, bis die "Wolken" erscheinen....einfach mal 5 Minuten etwas anderes machen und dann nochmal gucken^^

Hi,
seit einiger Zeit hänge ich an folgendem Problem:
AutoIt-Script mit GUI ruft per MemoryFuncCall() ein eingebettetes Assemblerprogramm auf. Aus diesem Assemblerprogramm springe ich per Callback in eine AutoIt-Funktion _CB() und nach Abarbeitung einiger Berechnungen wieder zurück ins Assemblerprogramm. Das funktioniert einwandfrei.

Nun folgendes Problem:
Versuche ich, innerhalb der callback-Funktion _CB() das Programm "anzuhalten" (while 1 / wend), bekommt das Hauptfenster nach einigen Sekunden die Meldung "Keine Rückmeldung" . Das kann ich mit ersetzen der while/wend durch eine MsgBox() vermeiden. Das kommt wohl daher, dass die MsgBox() ein echtes modales Fenster ist, mit dementsprechendem Message-Handling.
In der GUI enthaltene Buttons kann ich natürlich per GuiRegisterMsg() auch während der Anzeige der Msgbox abfragen.

Frage:
Was muss ich machen um innerhalb der callback-Funktion ein Warteschleife (ohne Messagebox) zu realisieren ohne dass die GUI die "Keine Rückmeldung"-Message erhält?

Am liebsten wäre mir in der GUI ein "Weiter"-Button, der das angehaltene Script weiterlaufen lässt.
/EDIT/ habe mich schon mit subclasses beschäftigt, ohne da wirklich weiterzukommen. Ich vermute, dass durch die AutoIt/Assembler/callback-AutoIt-Kombination die Messages durcheinanderkommen, obwohl sie sich eigentlich im gleichen Thread(Adressraum) befinden.

Hi,

Zitat

Da wird einem aber was abverlangt xD

nicht wenn man zuerst die "simple" Methode verwendet.
Statt per Raytracer jeden Schnittpunkt der Oberfläche mit dem Ray auf sichtbar/unsichtbar zu prüfen, zeichnet man die "Landschaft" von hinten nach vorne. Aus dem "Punkt" (Pixel) in der Draufsicht wird nun eine senkrechte Linie in der Seitenansicht! Gewissermassen ein gefülltes Modell. Die Höhen werden entsprechend eingefärbt, unten grün, mitte grau/braun, oben weiss. Selbst in c++ sollte das schnell genug sein, ansonsten grabe ich mal einen schnellen "SenkrechteLinienAlgorithmus" aus der ASM-Asservatenkammer aus^^. Wenn man mit dieser einfachen Lösung auf nur halbwegs schnelle Ergebnisse kommt, sollte es eigentlich reichen.
Einen "richtigen" Raytracer kann man dann immer noch bauen...

Hi,
sehr schöne Demo!
Der Vorläufer zu einer Landschaft...
Dein Graustufenbild als Höhenkarte nehmen und entsprechend nach Höhe und lokaler Steilheit einfärben ist das nächste. Eine "Renderengine" dazu sollten wir auch noch hinbekommen, eine Sonne reicht ja erstmal^^
Allerdings wirds dann Zeit für eine Dll, C++ sollte wenigstens die Formeln und das Schreiben in die Bitmap schenller hinbekommen.

Hi,
bei meinen ersten Tests von Bitblt() und Transparentblt() habe ich noch Linien- und Kreisfunktionen (und Spiralen) "zu Fuss" in eine Bitmap (als Datei!) gezeichnet, und diese dann auf bewegten Hintergrund geblittet.
Vielleicht braucht ja jemand mal eine (Voll-)Kreisfunktion oder eine Linie^^
Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

Zitat

Ich würde sagen, viel Spaß mit der Funktion:

Umgesetzt in Autoit hätte ich das noch lustig gefunden, aber da du weder in der Lage bist die Funktion iGetIntegerAndFractional() noch myRandomMagic() zu erstellen, gehe ich davon aus, dass ausser C&P nicht mehr viel kommt....daher ein klares

Zitat

Mit dem Startwert kommt auch bei Random die gleiche Zahlenfolge raus, du musst nur die Funktion zum setzen des Startwerts finden.

hehe, DER war gut!

Bei Perlin-Noise geht es u.a. darum, dass es um einen bestimmten Random-Start-Wert herum nachvollziehbar zu denselben Ergebnissen kommt. Was man damit machen kann ist übrigens sehr schön hier beschrieben!

Hi,
da ein Prozessor (Computer) landläufig nur zwischen 0 und 1 unterscheiden kann, hat sich das auch in den Programmiersprachen durchgesetzt.
Sämtliche Fallunterscheidungen(IF,SELECT,SWITCH, und natürlich auch GLEICH = oder UNGLEICH <>, GRÖSSER > oder KLEINER <) orientieren sich somit an 0 oder 1, genau wie die Abbruchbedingungen von Schleifen (WHILE, DO) und noch viel mehr, z.B. Berechnungen. Bei irgendwelchen Abfragen wird IMMER NUR auf 0 oder 1 getestet!

Da Prozessorintern auch nur mit 0 und 1 gerechnet wird, übrigens per simpelsten Bausteinen wie AND-, OR-, XOR-, und NAND-Gattern kann man auch die 0en und 1en entsprechend "umrechnen".
Eine 1 an den Eingang eines NOT-Gatter angelegt, ergibt am Ausgang eine 0 und umgekehrt. Die Computersprache orientiert sich IMMER an der Hardware (an was sonst^^) und macht demnach aus einem NOT 1 eine 0...
Da aber die "Computer-Hochsprachler" sich zu fein waren, sich mit schnöden Nullen und Einsen zu befassen, ersetzten sie 1 mit TRUE und 0 mit FALSE. (Wahr und nicht wahr). Wenn man also einen Ausdruck mit WAHR bezeichnet, dann entspricht das 1, bei UNWAHR dementsprechend 0. NOT TRUE entspricht FALSE und umgekehrt.

*whisper an die Insider* deshalb bin ich gespannt wie ein Flitzebogen auf die Programmiersprachen eines Quantencomputers *whisper out*

Und somit ergeben sich die Fallunterscheidungen....
Beispiel:

If 1 Then MsgBox(0, "Info", "If-Abfrage hatte Ergebnis 1=True")
If True Then MsgBox(0, "Info", "If-Abfrage hatte Ergebnis True=1")
If 0 Then MsgBox(0, "Info", "Coole Programmiersprache!") ; wenn man diese MsgBox sieht, wirds bitter...
If Not 0 Then MsgBox(0, "Info", "NOT 0 macht der Prozessor zu 1, und dann stimmts!");
If Not False Then MsgBox(0, "Info", "NOT FALSE macht die Programmiersprache zu TRUE und der Prozessor zu 1, und dann stimmts!"); exit

While 1 ;solange hier 1 oder TRUE steht, läuft die Schleife weiter
wend

While NOT FALSE ;läuft ebenso endlos
wend

Da GLEICH natürlich auch nur eine Fallunterscheidung ist, gilt dasselbe. Da GLEICH aber auch gleichzeitig (sic) eine Wertzuweisung ist, gibt es ab und zu Stolpersteine!
Einige Programmiersprachen lassen die Wertzuweisung innerhalb einer Fallunterscheidung zu....was sicherlich dem erhöhten Drogenkonsum in den 70er und 80er Jahren geschuldet ist^^. Glücklicherweise gehört AutoIt nicht dazu!

$a = Not False ;Wertzuweisung, der Inhalt von $a ist TRUE
If $a Then MsgBox(0, "Info", "Abfrage auf TRUE erfolgt!")

$a = 53 ;Wertzuweisung, der Inhalt der Variable $a ist 53
MsgBox(0, "Ergebnis $a=53 ist:", $a = 53) ;Hier ist das Gleich = eine WAHR/UNWAHR-Unterscheidung, also TRUE!
MsgBox(0, "Ergebnis $a=24 ist:", $a = 24) ;Hier ist das Gleich = eine WAHR/UNWAHR-Unterscheidung, also FALSE!

$a=4 ;Wertzuweisung, Variable $a erhält den Wert 4
;in der folgenden Zeile ist das = eine Fallunterscheidung TRUE/FALSE
if $a=4 then Msgbox(0,"Ergebnis","Der Inhalt der Variablen $a ist gleich 4, daher ist das Ergebnis TRUE, und man sieht die Messagebox!")
if $a>0 then Msgbox(0,"Ergebnis","Der Inhalt der Variablen $a ist grösser als 0, daher ist das Ergebnis TRUE, und man sieht die Messagebox!")

Wer aufgepasst hat, konnte vielleicht erkennen, dass ein "IF TRUE THEN" nur ein TRUE ist, und dieses wiederum mit dem Ergebnis eines Vergleichs ($a=4) übereinstimmt! Man kann also völlig auf IF verzichten!

$a = 4 ;Wertzuweisung
If ($a = 4) Then ;wenn Klammerausdruck wahr, dann
$ergebnis = 50 ;ergebnis auswählen
Else ;ansonsten
$ergebnis = 60
EndIf
MsgBox(0, "ergebnis=", $ergebnis)

;Das IF/ELSE Konstrukt kann man durch eine Zeile ersetzen
$ergebnis = ($a = 4) * 50 + ($a <> 4) * 60 ;wenn ($a=4) TRUE ist, dann entspricht das 1, und 1*50 ist 50....dann ist ($a<>4) aber 0, und 0*60 ist 60...und umgekehrt
MsgBox(0, "ergebnis=", $ergebnis)

;oder gekürzt
$ergebnis = 60 - ($a = 4) * 10 ;60 minus TRUE(=1) *10 ist 50, und 60 minus FALSE(=0)*10 ist 60
MsgBox(0, "ergebnis=", $ergebnis)

Ich habe keine Ahnung, welche Berechnung (IF oder der Einzeiler) schneller oder langsamer ist, aber eins ist klar, einige dieser Zeilen in ein Script eingestreut ersparen einen Obfuscator definitiv.
Man kann natürlich mehrere ineinandergeschachtelte IF-Abfragen in eine einzige Zeile packen! Wenn es schon den Code nicht lesbarer macht, dann erfordert es wenigstens etwas Gehirnschmalz beim Leser, und führt zum einen oder anderen "OHA"-Effekt

Ich hoffe, nun alle Klarheiten bezüglich IF/THEN, TRUE/FALSE und 1/0 restlos beseitigt zu haben

Somit sollte auch die Verwendung von BITAND, BITOR oder BITXOR möglich werden, denn mit Nullen und Einsen kennt man sich ja nun aus