Beiträge von Andy

Zitat von Musashi

Handelt es sich bei der von Dir angesprochenen 'letzten echten Freeware' von IDA denn überhaupt um die Version 5.0 ?

Ja, 5.0 habe ich. Wobei ich auch noch eine ältere Version habe, die imho auch "einfacher" ist. Die ist aber auf meinem Rechner zuhause, bin zzt. unterwegs, hab daher die Version nicht.

Aber 5.0 ist schon ok. Was man damit gegenüber der "PRO"-Version nicht machen kann, habe ich zumindest auch noch nicht vermisst^^

Für die Puristen, man kann auch den KD (KernelDebugger) aus Windows nutzen, damit wühlt man sich durch ALLE Eingeweide an Code, heißt nicht umsonst KernelDebugger, damit kann man auch mal Treibern auf den Pelz rücken und andere eklige Sachen machen. Den KD habe ich auch ab und zu im Einsatz, aber immer weniger...man macht auch weniger, wo man solche Werkzeuge braucht :o)

Um zu schauen, was Compiler aus Sourcecode machen, nutze ich auch https://godbolt.org

Die haben etliche Compiler zur Auswahl, u.a. auch den ICC, den sich Otto Normalprogrammer nicht unbedingt leisten muss. Aber sehr fein, was der gegenüber den anderen Compilern aus dem Code rausholt bzw. "optimiert", sehr beeindruckend!

Ansonsten gibt´s doch auch "AssembleIt64", incl. Debugger, da kann man auch schon recht viel mit machen

AssembleIt V121.zip

Zitat von Musashi

Allerdings traue ich dem 'sicheren Chip-Installer' nicht über den Weg

Hab jetzt auch mal nachgeschaut, der CHIP-Installer ist brauchbar, wenn man die 2-3 nicht benötigten Programme NICHT installiert^^

Das impliziert allerdings, NICHT auf jeden sofort erreichbaren Button zu klicken, sondern auch den Text im Fenster zu lesen....

Ich weiß, gerade für die "Pro´s" die 5x in der Woche ihren Rechner neu aufsetzen (müssen), ist das SEHR viel verlangt!

@Musashi,

Ich habe die letzte "Free"-Version seit deren Erscheinen auf meinen Rechnern, daher weiss ich auch nicht, wo die herkam....

Zitat von Mars

Und TATSACHE, ich speichere in xmm0 die Gesamtabweichung über alle Pixel und gehe davon aus, dass es 0 initialisiert ist. Bist du Hellseher? Woher wusstest du das? (Der Code war nicht beigelegt. Da war wohl Dr. Decompile am Werk, oder deine Glaskugel ist meiner weit überlegen)

Auf meinem Rechner benutze ich diverse Werkzeuge fürs Disassembling/Debugging (gut ist imho die letzte "freie" Version von IDA, solltest du unter IDA PRO FREE finden), aber um sich mal einen schnellen Überblich zu verschaffen schaue ich HIER https://onlinedisassembler.com/static/home/index.html

IDA nehme ich gerne, um mir "dubiose" DLL´s und auch die Ergüsse von diversen Compilern anzuschauen....

Zitat von Mars

PS Der Code kommt eigentlich komplett ohne SSE aus, xmm wird nur zum hochzählen verwendet weil ein Register gefehlt hat

So mache ich das idR auch, allerdings bringt das bei den neuen Prozessoren nichts oder nur sehr wenig an Geschwindigkeitsvorteil, da die Speicheranbindung über den Stack/Cache ein PUSH/POP auch in einem Takt abwickelt. ASM ist VIEL entspannter geworden^^

Und wie gesagt, wenn dein Code funktioniert und du was gelernt hast, um so besser, da machen die Handvoll eingesparter oder "verschwendeter" Takte nichts aus.

Zitat von Mars

(Wollte aber nicht zu viel Arbeit reinstecken, weil ich darin keinen Flaschenhals sehe,

Richtig!

Zitat von Mars

Was ich nämlich unter allen Umständen vermeiden möchte ist sowas wie dass das gleiche Teilbild 50x verwendet wird, nur weil es gut passt. Das mag zwar rechnerisch ein besseres Ergebnis liefern (und vllt auch auf den ERSTEN Blick optisch, aber sobald man näher hinsieht springt einem das ins Auge und man bekommt sofort Krebs).

Ja, das kann bei "guten" Pixeln und Massen davon in einer Fläche zu unschönen Mustern führen, aber das könnte man bspw. durch die zufällige Auswahl unter den x " am besten passenden" Pixeln kompensieren.

"Näher hinsehen" darf man sowieso nicht, allerdings habe ich festgestellt, dass man auch bei vermeintlich schlechten Ergebnissen durch zusammenkneifen der Augen und das dadurch "verschwimmende" Sehen erkennen kann, was auf dem Bild dargestellt ist.

Zitat von Mars

Ich schätze allein durch ein paar Umstellungen hat man bei gleicher Funktionalität ca. 10-100x mehr Geschwindigkeit (sodass man auch ein FullHD Bild in einigen Sekunden verarbeiten kann).

Davon gehe ich auch aus....

Ggf. könnte man sogar einen Pool von Bildern/Verzeichnissen vorberechnen, diese "Pixel" indizieren und dann verwenden.

Die "Farbe" analysieren, diese als Index verwenden und auf das "Pixel" zugreifen wird wohl die schnellste Methode sein.

...oder man verwendet keinen Zufallsgenerator, sondern erstellt das nächste Zeichen über eine Berechnung/Formel, deren Wert sich immer wiederholt, bspw. Sinus.

Hi,

um zu vergleichen, ob ein bestimmter String in einem anderen enthalten ist, verwendet man StringInstr().

Hi,

ich finde die Laufzeit sooo schlecht nicht einmal, und auch das Ergebnis ist imho völlig ok, aber ggf kann ich dir hier weiterhelfen:

Zitat von Mars

und aus irgendwelchen Gründen gibt mein ASM manchmal nichts aus, wenn man zu schnell auf den Speicher zugreift, daher das Sleep(0) vor jedem Aufruf)

initialisiere "ganz oben" im Code das xmm0, bevor du es erstmalig ausliest!

Ich vermute, du gehst davon aus, dass der Wert 0 ist?!

Die Inhalte der XMM-Register enthalten, genau wie die meisten anderen Register auch, beim Einsprung in eine ASM-Funktion irgendwelche "übriggebliebenen" Werte!

Kann gut sein, dass die Sleep()-Funktion von AutoIt "zufällig" auch XMM-Register beeinflusst!

Und ohne das Sleep() steht dann in XMM0 irgendein Wert, der dir deine gesamte Berechnung durcheinanderhaut....

//EDIT

Habe jetzt mal deinen Code analysiert und einige Bilder "berechnet". Im ursprünglichen Algorithmus wird, bedingt durch das "shuffle" der Teilbilder, bei der Verwendung der "letzten" (nicht passenden) Teilbilder auch das ansonsten SEHR ansehnliche Ergebnisbild durch mehr oder wenige "unpassende" Pixel verschandelt.

Ich habe den Code jetzt so abgewandelt, dass

- die Abfrage If IsDllStruct($aIMG_Dst[$aPosDst[1]][$aPosDst[0]]) And IsDllStruct($aIMG_Src[$y][$x]) Thenkomplett entfernt werden kann, indem die Teilbilder nicht mehr gelöscht werden.

Somit entfallen die "unpassenden" Pixel völlig und es wird für jedes Pixel das "passende" Gegenstück gefunden. Doppelte kann und muss es da natürlich geben, sieht aber Welten besser aus!

Die Laufzeit wird um Äonen schneller, wenn du die "Differenz" der Pixel nicht jedes mal neu berechnest, sondern einfach einen "Mittelwert" der Farben RGB für jedes Teilbild (durch ASM-Code ermittelt) in einem Array (Struct) abspeicherst, und dann einfach das "nächste passende" suchst. Da würde sich auch sicher noch mehr optimieren lassen, ggf durch Indizierung.

Jedenfalls ist nicht der ASM-Code die Begrenzung der Laufzeit, sondern wie üblich in diesen Fällen die vielen ineinander verschachtelten Schleifen, die der arme AutoIt-Interpreter durchnudeln muss....

//EDIT2

Wenn man dein Script mit dem Ansatz lässt, alle Pixel nur ein mal zu verwenden, dann bietet es sich an spiralförmig von der Mitte aus das Bild (R) zu füllen. Somit werden die "unpassendsten" Pixel immer am Rand verarbeitet und stören weniger. Bei völlig unterschiedlichen Q und Z bildet sich dann ein "Rahmen" der ggf. völlig neue Ansichten bietet^^

Zitat von alpines

Teilweise ist das auch verständlich, Script-Breaking Changes gehören einfach dazu, man kann nicht 20 Jahre in die Zukunft schauen und dafür vorprogrammieren.

Das sehe ich nicht so. Eine Programmiersprache ist in aller erster Instanz erst mal eine Summe von Befehlen, aka FUNKTIONEN.

Und das was diese Funktion macht, bestimme ich als Programmiersprachenersteller. Ich bestimme aber auch, wie diese Funktion heißt.

Ergo habe ich bei einer Entwicklung die Möglichkeit, eine (gewollte) Verbesserung innerhalb des Funktionscodes so durchzuführen, dass die Ergebnisse der Funktion mit der der Vorversion übereinstimmen.

Wenn ich an der Funktion die von dir beschriebenen "Script-Breaking Changes" durchführe, schiesse ich mir als Ersteller einer Programmiersprache permanent ins Knie!

Beispiel Funktion(), da könnte ich haufenweise Änderungen und "Script-Breaking Changes" dranhängen, ich könnte aber auch Funktion1(), Funktion2(), FunktionXX(), FunktionYY() uswusf erstellen, mit individuellen, "weiterentwickelten" Eigenschaften. Wer bin ich denn als Programmiersprachenersteller, einem "Programmierer" vorschreiben zu wollen, was er letztendlich zu tun und zu lassen hat?!

Was mache ich denn als Programmierer, wenn der Programmiersprachenersteller GENAU DIE Funktion, deren Ergebnis ich GENAU SO haben wollte, einfach ändert?!

Mein Programm so umschreiben, "..dass es wieder passt.."?!

Ich habe neulich einen tollen Beitrag im Blog von Agner Fog gelesen. Dort beschreibt er, wie die Prozessorhersteller mit jeder Generation "tausende" neue Befehle aus ihrem Silizium quetschen, und die Krux, mit jedem "neuen" Prozessor die uralten Abhängigkeiten (aka "Abwärtskompatibilitäten") mitschleppen zu müssen.

Natürlich schreitet die Entwicklung voran, aber lieber Agner Fog, die Handvoll 40 Jahre alten x86-Befehle sind definitiv NICHT das Problem in einem neuen Prozessor!

Es ist die SOFTWARE, die diese 40 Jahre alten Prozessorbefehle zu 99% heute noch nutzt! Und Compiler, die mir als User zwar "neue" Befehle anbieten, aber als "Intrinsics"? Was soll denn DER Schei***? Esoterische Programmiersprachen werden erfunden, damit letztendlich Maschinensprachebefehle eingegeben werden müssen?

Wo ist denn der Compiler, der keinen der alten, "obsolet" gewordenen Prozessorbefehle mehr nutzt?

Wenn nicht der Prozessorhersteller, wer denn bitteschön sonst kann einen "neuen" Compiler zum passenden innovativen, "neuen" Prozessor mit all den tollen neuen Features zur Verfügung stellen?

Ich bin überzeugt, aus technischer Sicht bestünde da absolut kein Problem. Ich vermute nur sehr stark, die wirtschaftlichen Gründe entscheiden, sprich man muss den immer fleissig zahlenden Kunden möglichst langfristig in einer Abhängkeit halten! Jedwege revolutionäre Änderung würde einen bisher vom Produkt abhängigen Kunden sofort nach (ggf sogar "besseren") Alternativen Ausschau halten lassen! (ähhhm, Parallelen zu AutoIt?!)

In dem Moment in dem bspw. ein Prozessorhersteller einen innovativen "neuen" Prozessor incl. Programmierumgebung vorstellt, ziehen ALLE anderen Anbieter SOFORT nach, denn die sind ja auch nicht blöd und haben solch ein System längst auch in der Schublade.

Damit würden aber ALLE Karten im Markt neu gemischt, und DAS tut sich keiner der global Player an!

Solange man Milliarden damit verdient, auf neuester Hardware uralte Software laufen zu lassen, ändert sich auch nichts!

Und damit schließt sich aber auch der Kreis zum Anfang meines Posts!

In meinem allerneuesten Prozessor kann ich immer noch 8-Bit-Befehle ausführen, wenn ich das will! Und die liefern GENAU das gleiche Ergebnis wie vor 40 Jahren!

Natürlich kann ich auch AVX512 Befehle ausführen, aber diese sind, und genau DAS war so beabsichtigt, eine Erweiterung des Befehlssatzes, und kein Ersatz!

Wieso macht man das nicht genau so bei einer Programmiersprache?

Was wäre an AutoIt schlechter geworden, wenn ich heute mit der neuesten Version mein 10 Jahre altes Script kompilieren (sic) könnte?

Oder wäre AutoIt eventuell sogar dadurch "besser" als andere, "modernere" Sprachen?

Zitat von alpines

An einem bestimmten Punkt befindet man sich einfach in einer Sackgasse

...in die man sich genau durch dieses Vorgehen selbst reingeritten hat...

Zitat von alpines

und muss den bisherigen Zweig komplett wegschmeißen oder sich irgendeine wackelige Konstruktion zurechtfriemeln

...unter der wir alle, die mit "alten" Scripten zu tun haben, leiden müssen!

Zitat von alpines

Win32 Controls kommen allmählich ziemlich in die Jahre und für die neuen Controls gibt es glaube ich sowas wie AutoIt Window Info noch nicht.

Auch damit kämpfe ich fast jeden Tag, mittlerweile ist es schon problematisch, ein "Fenster" in den "Vordergrund" zu holen. Das ist aber nicht das Problem von AutoIt, sondern von WIN10. Ich habe jetzt wirklich vor, in der Firma einen Rechner auf Win7 "downzusizen" und die seit vielen Jahren problemlos laufenden Scripte LOKAL (nicht im RDP) in Verbindung mit Drittherstellersoftware laufen zu lassen.

60FPS im Fullscreen, damit kann (muss) man leben! :o)

Und der "Neo" toppt natürlich alles!

Einfach schön....

Aber ich werde nie ein Fan von GDI+, denn alleine die beiden Zeilen

DllCall($__g_hGDIPDll, "int", "GdipFillRectangle", "handle", $hCanvas2, "handle", $hBrush_Bg, "float", 0, "float", 0, "float", $iW, "float", $iH)
DllCall($__g_hGDIPDll, "int", "GdipFillRectangle", "handle", $hCanvas, "handle", $hBrush_Clr, "float", 0, "float", 0, "float", $iW, "float", $iH)

"kosten" so viel, wie der gesamte andere Code im Loop zusammen

Irgendwann in grauer Vorzeit hatte ich mal übers Blitten dieses Abdunkeln hinbekommen, das war dann echt fix. Ich werde mal suchen....

Zitat von BugFix

Der Dateiname wird für die PDF-Erstellung aber schon genutzt (aus Bsp. 'RE0815.doc' wird 'RE0815.pdf')

Es gibt beim Druckvorgang kein kein "RE0815.bla-Dokument"! Da wird eine Seite an einen Drucker gesendet, genau DAS ist ja sein Problem! Leitest du dann auf einen PDF-Drucker um, fragt dieser dann "natürlich" nach dem Dateinamen oder nimmt den "Standard"-Dateinamen, der meist irgendwo hinterlegt werden kann (im PDF-Druckertreiber....)

chesstiger

Ich löse das Problem bei uns in der Firma folgendermaßen:

Die ins System an diesem Tag eingegebenen Aufträge werden 1-2x am Tag "abgearbeitet". Ich habe das Glück, die ERP-Systemdatenbank anzapfen zu können, da hole ich mir erstmal alle "neuen" Aufträge, die dann nacheinander abgewickelt werden. Von der Erstellung und Überspielung von Maschinendaten bis zum u.a. "drucken" von PDF´s läuft alles über EIN AutoIt-Script, welches die ERP-Anwendung komplett für den jeweiligen Vorgang fernsteuert.

Die PDF´s werden dabei je nach Ziel (AB,LS, RE usw.) mit Auftragsnummer und ggf. weiteren Infos im Dateinamen abgespeichert.

Dabei erkennt mein Script "automatisch" (die Scriptsprache heißt ja Auto :o) It , sorry, DER musste jetzt sein^^) den aktuellen Zustand des Auftrags.

Auftrag wurde erfasst -> Alle Systemdaten erstellen und Maschinendaten und Listen für die Produktion erstellen

Auftrag wurde gefertigt -> Packlisten und Ladelisten erstellen

Auftrag wurde Kommissioniert -> Bereit zur Auslieferung

Auftrag wurde ausgeliefert (LS wurde erstellt) -> Info an Buchhaltung für Rechnungserstellung (mit anschließender "automatisierter" Rechnungserstellung)

Wenn du keinen Zugriff auf die Datenbank hast, wirst du wohl schlechte Karten haben.

Ansonsten greifst du dir die aktuellen laufenden Aufträge und machst mittels Script genau das, was der Mitarbeiter machen würde....Buttons klickern....

Und da du ja den Status weißt, bzw. auch das von einem Script zur Not vom Mitarbeiter abfragen lassen kannst, brauchst du "nur noch" die richtigen "Knöpchen drücken"

Die Mitarbeiterin, die den Auftrag erfasst hat und jetzt einen Lieferschein drucken will, drückt nun nicht mehr im ERP-Programm 19 Buttons (bei uns ist das so, DAS war der Grund, mein Script anzufangen...) sonder startet bspw. dein Script per Hotkey und wählt dort "LS drucken" und guckt die 5 Sekunden zu, wie das Script klickert und IMMER den richtigen Drucker wählt.

Zitat von BugFix

Kam mir im Moment, als ich das erstellt habe leider nicht in den Sinn, dass diese Klammern auch normaler Text sein können.

Mir kommt (genau wie dir) überhaupt nicht in den Sinn, was geschweifte Klammern in einem mit Variableninhalten anzuzeigenden und zu formatierenden TEXT (!) zu tun hätten....

Vor allen Dingen dann, wenn ich als Anwender der Funktion WEISS, dass diese Zeichen relevanter Funktionsbestandteil sind!

@Musashi, wo ist der Fehler im linken Bild?

$text="Das ist ein Text, der die Variable $i mit dem Inhalt %i ausgibt"
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $text = ' & $text & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

$stringformatiert=stringformat ($text,12345)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $stringformatiert = ' & $stringformatiert & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

;und jetzt für die hardliner...
$text="Das ist ein Text, der haufenweise Prozentzeichen, bspw. 'Mutti hat 100%ig Recht!' enthält und die Variable $i mit dem Inhalt %i ausgibt"
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $text = ' & $text & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

$stringformatiert=stringformat ($text,12345)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $stringformatiert = ' & $stringformatiert & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

Hier käme NIEMAND auf die Idee, dass "100%ig" im Text "erlaubt", bzw. maskiert werden müsste. Oder doch? Dann schreibt mal ein Ticket an die DEV´s vom StringFormat()!

Alternativ zu den geschweiften Klammern kann man ja eins der vielen vielen Steuerzeichen oder allgemein "ungenutzten" Sonderzeichen im ASCII-Zeichensatz verwenden. Aber wie gesagt...nur selbst fressen macht fett!

Ich jedenfalls finde die Funktion klasse! Und falls mich irgendetwas daran stören sollte und/oder ich Ideen zu einer Verbesserung/Erweiterung habe, dann setze ich diese einfach um. Das mache ich mit vielen Codeschnipseln, die ich so aufschnappe. Die Fähigkeit, diese Schnipsel auf eigene Erfordernisse anzupassen scheint der Unterschied zwischen mir und den Horden von C&P-"Programmierern" zu sein.

Mir würde nie einfallen, dem Funktions-Ersteller erzählen zu wollen, dass an seiner (für seine Ansprüche) funktionierenden Funktion etwas "falsch" wäre.

Vor allem dann nicht, wenn die Funktion einwandfrei unter Beachtung der "Regeln" (hier: die geschweiften Klammern sind Funktionsimmanent) funktioniert.

/OT-Modus ON

*husthust* so wie ich das sehe, sind einige TOP-Leute hier aus dem Forum ursprünglich aus dem Lager der "Spiele-Vereinfacher" gekommen *räusper*

/OT-Modus OFF

Zitat von kaynewild

Achja eins sei fairerweise natülich noch gesagt: Ja auch ich versuche mir die programmierkenntnisse anzueignen um es mir bei einem game etwas einfacher zu machen.

Naja, wenn du Programmierkenntnisse NUR dazu brauchst, um beim Spielen zu bescheißen (auf neudeutsch heisst das ja "cheaten") , lass es, denn es ist die Mühe bei weitem nicht wert!

Bis du so gut als Programmierer bist, dass du kommerzielle Spielebots mit deiner Kunst ersetzen könntest, hättest du mit "ernsthafter" Arbeit wesentlich mehr Geld verdient.

Und selbst wenn du nur ein bisschen "cheaten" willst, die Stunden vor der Kiste, um ein Programm zu schreiben dass dir "virtuelle" Vorteile verschafft, sind im RL wesentlich besser investiert.

Frag diejenigen, die das hinter sich haben....

Hat aber nichts damit zu tun, dass hier die Regeln eingehalten werden müssen!

Wobei nichts gegen eine "schöne" GUI einzuwenden ist, und die Programm(ier(er))logik zu verstehen hat auch noch keinem geschadet.

Vielleicht hilft dir das sogar "später" mal in einem "richtigen" Beruf, in dem durch Arbeiten Geld verdient wird, und nicht durch cheaten.

Es soll Leute geben, die noch nie davon gehört haben, dass man so gut wie alle Microsoft-Produkte (Office gehört da auch dazu^^) per VBA (Visual Basic for Applications, als Sprache ähnlich AutoIt) "bearbeiten" kann.

Die Möglichkeiten beim Programmieren sind grenzenlos!

Hi!

Naja, ich finde, für einen Startpost in einem Programmier(er)-Forum (dazu erstmal ein "Willkommen!") ist da schon SEHR viel Potenzial vorhanden.

Eine ordendliche Frage ist gestellt und ein selbstgeschriebenes Script ist dabei, das ist schon mehr als man bei 90% aller "Starter" erwartet!

Da bleibt mir nur noch zu sagen: "Weiter so!"

Tip am Rande, schau dir die Signaturen der Forenmitglieder an, dort sind meist Anfängerfreundliche "Tutorials" zu dem ein- oder anderen Thema verlinkt...

Hi!

Wunderschön gemacht!

Und bei "großen" Monitoren ist es doppelt so schön :o)

Zitat von alpines

Bei solchen Zeiteinheiten sollte es, meiner Meinung nach, viel eher um die Gestaltung und den Stil des Codes gehen als noch das letzte bisschen Performance rauszuholen,

Genau darum geht es doch!

GESTALTUNG und STIL eines Codes haben essenziell mit der Wartbarkeit zu tun! Man schreibt doch nicht einen NICHT (gut) debugbaren Code, nur weil er "schön" aussieht?!

Oder heißt das etwa, man schreibt erst einen gut debugbaren Code, und macht ihn dann, wenn er fehlerfrei läuft, "schön"?

Zeit (im Sinne von Scriptlaufzeit) ist imho auch völlig überbewertet, jedenfalls bei vorliegendem Problem.

//OT-Modus ON

Wobei ich mal gerne einen Vergleich mit Texten >500.000 Zeilen sehen würde. Da ist die Stringfunktions-Variante wahrscheinlich mit dem "fertige Datei schreiben" schon fertig, bevor das FileReadToArray() durch ist....

Vom Regex ganz zu schweigen.

//OT-Modus OFF

Ich jedenfalls würde folgende Variante vorziehen. Jede Variable ist per ALT-D oder STRG+SHIFT+D abzufragen.

$ubound1=UBound($aMyArray)
$ubound2=1337
$ubound3=UBound($aMyArray, 3)

ReDim $aMyArray[$ubound1,$ubound2,$ubound3]
For $i = 0 To $ubound1 - 1    
    For $j = 0 To $ubound2 - 1
        For $k = 0 To $ubound3 - 1
            ;...
                ;$f=sqrt($ubound2)
                ;if $ubound1<$ubound2 then...
                ;$f=$ubound2^3
                ;else
                    ;for $x=$j to $ubound1
                    ;$f=$f/$x*$ubound3
                    ;next        
                ;endif
        Next
    Next
Next

Gefühlte 99% aller "Mein Script/Programm funktioniert nicht!"-Posts in sämtlichen Programmiersprachenforen haben GENAU DIESES Thema als Ursache!

Der Programmierer geht davon aus, das das Programm das tut, was er sich VORSTELLT, was es denn tun soll. Aber Überprüfung?! Fehlanzeige!

Wie kommen denn diese Posts zu einem befriedigenden Ergebnis, aka "fehlerfreiem Programm"?

Gucken irgendwelche mit dem "göttlichen Blick" behafteten Hacker auf den Code und "sehen" den/die Fehler? Sicher nicht.

Die setzen Breakpoints und überprüfen Werte, und bauen so nebenbei (wenn sinnvoll und erforderlich) ein "Errormanagement" auf.

Der Fehler wird lokalisiert und ausgemerzt. Denn gefunden wurde er mittels debugging, und das macht absolut keinen Spass, wenn der Code dafür nicht vorbereitet ist.

Zitat von alpines

Es sieht konsequenter aus und man muss nicht erst hochscrollen um zu wissen was da steht

Wenn die Anzahl Buchstaben des Funktionsnamens/Parameter übersichtlich ist, warum nicht, aber idR machst du das so

Local $tGM = _WinAPI_GetGlyphOutline($hDC, ChrW(77), $GGO_BITMAP, $pData)
Local $W = DllStructGetData($tGM, 'BlackBoxX')
Local $H = DllStructGetData($tGM, 'BlackBoxY')
Local $SIZE = $W * $H

und nicht so

Local $SIZE = DllStructGetData(_WinAPI_GetGlyphOutline($hDC, ChrW(77), $GGO_BITMAP, $pData), 'BlackBoxX') * DllStructGetData(_WinAPI_GetGlyphOutline($hDC, ChrW(77), $GGO_BITMAP, $pData), 'BlackBoxY')

Zitat von autoiter

die Regex-Lösung von Andy finde ich klasse(, hätte den Einzeiler aber nicht hinbekommen).

filewrite("ergebnis.txt",StringRegExpReplace(fileread("testdatei.txt"),"(?m)(^bla.*$)\r\n(blub.*$)", "$2" & @CRLF & "$1" & @CRLF & "ZZZZZZZZ"))

krank, aber geht^^

Wieso krank? Weil jegliche Möglichkeiten des Debugging ausfallen. Definitiv sind 99% der User solch einer von einem "Programmierer" erstellten Konstruktion nicht in der Lage, bei Fehlern auch nur den Ansatz für eine Lösungsmöglichkeit zu finden.

Ähnliches auch in den o.g. Scripten.

Zitat von autoiter

1. For $i = 0 To UBound($aFile) -1 Step 1
2. If $i < UBound($aFile) -1 And StringLeft($aFile[$i], 3) = '# 2' And StringLeft($aFile[$i + 1], 3) = '# 1' Then

Mal abgesehen davon, dass in jedem Schleifendurchlauf auf Ubound() geprüft werden muss, wird genau dieses Ubound() auch noch mehrfach innerhalb der Schleife verwendet. Das gehört VOR der Schleife einmal berechnet und dann in eine Variable. Diese Variable ist dann per Tastendruck zu debuggen...

Gleiches gilt für die StringLeft(). Die werden auch jedes mal neu berechnet

Der Einzeiler für´s Regex ist natürlich schwer zu toppen, aber ich hatte ja zur Bearbeitung von Texten (Strings) die Text(String)funktionen empfohlen.

Warum? Diese Stringfunktionen existieren seit Anbeginn aller Zeiten in jeder Programmiersprache. Es existieren nur eine Handvoll dieser Funktionen, und alle sind EINFACH!

Wenn man ein Mal verstanden hat, dass ein String (das muss keinesfalls nur eine Textdatei sein!!!) nur eine lange Schlange aufeinanderfolgender Zeichen ist, dann behaupte ich jetzt mit dieser Handvoll Stringfunktionen den größten Teil aller Programmierprobleme lösen zu können. Beispiele für ein superschnelles Pixelsearch, also Suchen von Bytefolgen innerhalb eines Bildes, sind mit einer Zeile Code, bzw. mit einem simplen StringInStr() machbar. In AutoIt sowieso, da dessen Stringfunktionen als in C++ kompilierte und optimierte Funktionen aufgerufen werden, und nicht durch den Interpreter abgenudelt werden!

Den Stringfunktionen sind die "Zeichen" egal, es können ALLE Zeichen bearbeitet werden. Also auch Binärdateien....

Mit der Darstellung (bspw. als "Text" auf dem Bildschirm bzw. im Editor) sieht das anders aus, da funkt das Windows dazwischen, welches bspw. ein NUL-Zeichen (chr(0)) als Textende interpretiert....aber dazu

Ein Beispiel, wie das Problem mit den extrem schnellen Stringfunktionen gelöst werden könnte:

;aligncomment=85
$string = "123" & @CRLF & _
        "bla80765656" & @CRLF & _
        "blub8768686" & @CRLF & _
        "8076876" & @CRLF & _
        "8767856" & @CRLF & _
        "75765" & @CRLF & _
        "bla89608686" & @CRLF & _
        "blub876086786" & @CRLF & _
        "blub98789733" & @CRLF & _
        "876543" & @CRLF & _
        "3bla543153" & @CRLF & _
        "74blubiuztuit56" & @CRLF & _
        "bla2321" & @CRLF & _
        "8976" & @CRLF & _
        "blub87686" & @CRLF & _
        "bla466432" & @CRLF & _
        "blub098987" & @CRLF & _
        "bla432312" & @CRLF & _
        "gfgfdlkhjjkhg" & @CRLF & _
        "igjg"

;strings in Variablen
$bla = "bla"
$blub = "blub"
$zusatzzeile = "ZZZZZZZZZZ" & @CRLF                                                   ;replacezeile
$len_blub = StringLen($blub)                                                          ;stringlänge

;los gehts
$bla_pos = StringInStr($string, $bla)                                                 ;erste Position von "bla" im Text finden

While $bla_pos                                                                        ;solange den folgenden Algorithmus durchführen, bis kein "bla" mehr im Text vorkommt

    $bla_zeilenanfang = StringMid($string, $bla_pos - 2, 2)                           ;die beiden Zeichen CRLF müssen vor dem bla stehen, dann ist das ein Zeilenanfang
    If $bla_zeilenanfang = @CRLF Then                                                 ;Zeilenanfang bla gefunden
        $bla_pos_crlf = StringInStr($string, @CRLF, 0, 1, $bla_pos + 1)               ;findet nächstes CRLF nach dem bla (zeilenende)
        $bla_zeilenlaenge = $bla_pos_crlf - $bla_pos                                  ;länge der bla-Zeile
        $blazeile = StringMid($string, $bla_pos, $bla_zeilenlaenge + 2)               ;inhalt der blazeile incl. vorherigem CRLF

        $zeilenanfang_blub = StringMid($string, $bla_pos_crlf + 2, $len_blub)         ;die ersten Zeichen der nachfolgenden Zeile...
        If $zeilenanfang_blub = $blub Then                                            ;...fangen mit blub an
            $blub_pos_crlf = StringInStr($string, @CRLF, 0, 1, $bla_pos_crlf + 1)     ;position des CRLF am Ende der Zeile blub
            $blub_zeilenlaenge = $blub_pos_crlf - $bla_pos_crlf                       ;länge der blub-Zeile
            $blubzeile = StringMid($string, $bla_pos_crlf + 2, $blub_zeilenlaenge)    ;inhalt der blubzeile

            $bla_und_blub_zeilen = $blazeile & $blubzeile                             ;die beiden aufeinanderfolgenden Zeilen in einen string

            $blub_und_bla_und_zusatz_zeilen = $blubzeile & $blazeile & $zusatzzeile   ;Zeilen tauschen und mit zusatzstring ergänzen

            $string = StringReplace($string, $bla_und_blub_zeilen, $blub_und_bla_und_zusatz_zeilen) ;alle (!) vorkommenden Zeilen im Text  ersetzen

        EndIf
    EndIf
    $bla_pos = StringInStr($string, $bla, 0, 1, $bla_pos + 1)                         ;nächstes vorkommen bla finden
WEnd

MsgBox(0, 0, $string)

Zitat von Bitnugger

Das geht natürlich auch...

Ich bin nicht der große regexer, aber so etwas einfaches bekomme ich dank https://regex101.com auch hin :o)

Du hast das \R verwendet , ich hab´s aufgedröselt...hätt ich mal in die AutoIt-Hilfe geschaut, da steht´s drin.

Zitat von Bitnugger

'... viele Zeilen' & @CRLF

hach, wie profan....pah!

Spass beiseite, so simpel geht das alles bei regex101.com

Zwischenablage01.jpg

Im rechten Feld wird jede Eingabe erklärt, echt klasse, darunter werden die "Treffer" angezeigt, und darunter in der Reference....naja....da sucht man sich zusammen, was man an den ganzen kryptischen Zeichen so braucht. Ich muss da auch immer reingucken, selbst für so simples Zeug wie den Unterschied von .* und .+ reicht meine Gehirnkapazität nicht (mehr) aus. Aber Wissen ist wissen, wo es steht!

....immer noch Array...

Naja gut, hier meine Anleitung zum Copypaste für den Einzeiler

#include <Array.au3>
$string="123" & @crlf & _
"bla80765656" & @crlf & _
"blub8768686" & @crlf & _
"8076876" & @crlf & _
"8767856" & @crlf & _
"75765" & @crlf & _
"bla89608686" & @crlf & _
"blub876086786" & @crlf & _
"blub98789733" & @crlf & _
"876543" & @crlf & _
"3bla543153" & @crlf & _
"74blubiuztuit56" & @crlf & _
"bla2321" & @crlf & _
"8976" & @crlf & _
"blub87686" & @crlf & _
"bla466432" & @crlf & _
"blub098987" & @crlf & _
"bla432312" & @crlf & _
"gfgfdlkhjjkhg" & @crlf & _
"igjg"

filedelete("testdatei.txt")
filewrite("testdatei.txt",$string)

$text=fileread("testdatei.txt")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $text = ' & $text & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

$pattern=("(?m)(^bla.*$)\r\n(blub.*$)")
;pattern testen ist immer gut^^
$ret=StringRegExp($text,$pattern,3)
_arraydisplay($ret)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ret = ' & $ret & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

;die zzzzzzusätzliche zeile
$z="zzzzzzzz"

;zusammen
$ret=StringRegExpReplace($text,$pattern,"$2"&@crlf&"$1"&@crlf&$z)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ret = ' & $ret & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

;einzeiler......bissl Copy/paste bekommst du doch hin^^

Hi zusammen?

Wieso Array? Ich dachte es geht um einen Text?!

Komplette Datei einlesen, die beiden Zeilen mit den entsprechenden "Anfängen" finden, tauschen und (mit der 3.Zeile ergänzt) stringreplacen.

Um Texte zu bearbeiten verwendet man entsprechende Textbearbeitungsfunktionen, so sehe ich das jedenfalls. Arrays braucht dabei kein Mensch! Ein Regex macht das geforderte in einem Einzeiler.....und diesmal in einem "richtigen" Einzeiler^^

Glücklichen Herzwunsch und alles Gute!

Und vielen Dank für deine Mühe und Arbeit, von der wir anderen hier gar nichts mitbekommen....