Beiträge von Andy

so?

Global $Array[22] = [187, 190, 191, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 221, 222, 224, 228, 230, 231, 232, 237, 239]
ReDim $array[UBound($array) + 2] ;array aufbereiten für Suche

$text = "" ;arrayinhalt nach textinhalt
$delimiter = "" ;Trennzeichen im Text

For $i = 0 To UBound($Array) - 3 ;array durchlaufen
If $array[$i + 1] = $array[$i] + 1 And $array[$i + 2] = $array[$i] + 2 And $delimiter <> " to " Then ;3 aufeinanderfolgende zahlen gefunden?
$delimiter = " to " ;dann "to"
$text &= $array[$i] & $delimiter ;"to" einfügen
ElseIf $array[$i + 1] <> $array[$i] + 1 Or $delimiter <> " to " Then ;nicht aufeinanderfolgende gefunden
$delimiter = ", " ;ansonsten Trennzeichen ", "
$text &= $Array[$i] & $delimiter ;zusammen mit arrayinhalt
EndIf
Next
$text = StringTrimRight($text, 2) ;letztes Komma weg
ReDim $array[UBound($array) - 2] ;array wiederherstellen

$vorgabe = "187, 190, 191, 206 to 215, 221, 222, 224, 228, 230 to 232, 237, 239"
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $vorg = ' & $vorgabe & @CRLF) ;### Debug Console
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $text = ' & $text & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

//EDIT: kürzer^^

Zitat

Der Deal hier ist wohl eher die Mathematik. ASM empfiehlt sich

so ist es, dann kann man nämlich auch komplett die sin(), cos() und tan()-Funktionen durch konstanten ersetzen, da diese sowieso aufeinanderfolgen.
Allerdings bringt diese Beschleunigung in AutoIt garnichts, da der Interpreter in etwa dieselbe Zeit für ein v1+v2 braucht wie für ein sin().
In einer Compilersprache bringt das Faktor 20-30 an Geschwindigkeit! /
Ich such mir gerade nen Wolf....
//EDIT gefunden Ersetzen von Sinus in einer Schleife, beschleunigt den code um Faktor 30

Faszinierend, was man mit diesen "billigen" Formeln alles machen kann...
Da würde ich mich gerne nochmal in eine Vorlesung setzen und einige Wochen Tips, Tricks und Kniffe abschauen.
Hat jemand einen guten Tip für etwas lesbare, also verständliche Kost abseits von Differentialrechnung (kann das zwar noch einigermassen, aber das ist soooo mühselig...:( )

Wieso starten wir nicht einfach ein Gemeinschaftsprojekt, an dem JEDER AutoIt-User mitarbeiten kann?

Die "Engine" zum Berechnen einzelner Frames haben wir ja , die Handvoll Formeln ganz zum Schluss in eine C/C++/PowerBasic-Dll zu Giessen ist dann nur noch der letzte Schritt!
Bis dahin könnte aber jeder, der Interesse hat, einzelne "Bauteile" beisteuern.

Anbei ein weiterer Schritt in Sachen "Landscape", beim Sonnenauf- und Untergang werden die Farben angepasst

Weiterhin wird jetzt jeder gerenderte Frame angezeigt.

Um das mal jetzt weiterzuspinnen, die Bäume könnten Schatten abhängig vom Sonnenstand bekommen, richtiges "Gras" bzw. "Strand" könnte eingefügt werden, Wolken, Schiff fährt in den Sonnenuntergang, Tiere laufen durch den Wald uswusf.
Prozeduraler Sound?!
Jeder einzelne dieser "Bausteine" kann von jeweils einem Programmierer unabhängig vom Rest beigesteuert werden.
Es ist einfach nur die "Prozedur" für den jeweiligen Baustein zu erstellen, welcher dann einfach ins Script eingefügt werden kann...

Würde euch so etwas interessieren?
Jedenfalls würde man sehr viel über Mathematik erfahren

UEZ,
man könnte sich das Gras und die Bäume abschauen

DllStructSetData($tBMI, 1, DllStructGetSize($tBMI) - 4)
DllStructSetData($tBMI, 2, 400)
DllStructSetData($tBMI, 3, 400)
DllStructSetData($tBMI, 4, 1)
DllStructSetData($tBMI, 5, 32)

Made my day , wer braucht schon Konstanten, die vielleicht doch wieder geändert werden

Durch SB-Link nach hier inpiriert^^

Bitte noch eine Sonne dazu, und Schmetterlinge....

Hi,
obwohl bereits auf gelöst gesetzt, im Anhang (Appendix) der AutoIt-Hilfe findet sich eine Ascii-Tabelle....

Hi,
ich weiss nicht, ob mein "Problem" überhaupt hier hin gehört.
Beim Testen des OpenGl-Beispiels ist mir aufgefallen, dass alle 6 Cores meiner CPU auf Höchstleistung laufen?!
Daraufhin habe ich andere AutoIt-OpenGl-Beispiele ausprobiert und dort dieses Phänomen auch festgestellt.
Ist das bei euch auch so und an was liegt das?
System Win7-64
FX-6300
Radeon 7790
Catalyst-Treiber 13.12
OpenGL-Version 6.14.10.12618

Hehe, hab ab und zu herzlich gelacht!
Bin ja normalerweise nicht dafür, aber man sollte die Sprüche nummerieren um den "Spruch des Jahres" zu wählen
Hab da einen eindeutigen Favoriten

misterspeed,
teste mal bitte, ob dein Script auch funktioniert, wenn du im Pfadnamen Leerzeichen drin hast

Hi,
probiere das mal.
Wenn in der Msgbox etwas dargestellt wird, einfach mit deinem Programmnamen testen

#include <Constants.au3>

$programm = "dir"
$parameter = "c:" & Chr(92) & "program files (x86)" ;Backslash....:(

;ggf auskommentieren
;~ $programm="C:\Program Files\RevoUninstaller\RevoCmd.exe"
;~ $parameter="/m keepass"

$string = '"' & $programm & " """ & $parameter& """"
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $string = ' & $string & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

;'"' setzt bei Pfadnamen mit enthaltenen Leerzeichen erforderlichen Anführungsstriche
Local $out = Run(@ComSpec & " /c " & $string, @ScriptDir, @SW_HIDE, $STDERR_CHILD + $STDOUT_CHILD) ;Programm anpassen
Local $line
While 1
$line &= StdoutRead($out)
If @error Then ExitLoop
WEnd
MsgBox(0, "StdoutRead", $line)

//EDIT, klasse, dass die Backslash nicht dargestellt werden

Hi,
wieder einmal wird bestätigt, dass auch für einfachste Botterei ein Minimalskill erforderlich ist...
Seltsam, dass die ImageSearch() bei tausenden Bottern einwandfrei funktioniert, aber in diesem Fall nicht?!

Wieso ich auf Botten komme?
Siehe die bisherigen Threads des TE seit seiner Anmeldung...

alpines,
hier im Forum existieren seit Jahren mehrere Scripte, welche die Funktionen des "Bildersuchens" (was nichts anderes ist als eine Pixelsuche) in nativem AutoItcode bei Suche auf dem gesamten Screen in einigen ms vollführt.
Das Programm hilft sogar beim Erstellen der Suchbilder, welche sogar animiert sein können...also bewegt, s. bspw. den oben von mir verwendeten Smilie.
Fensterinhalte werden bei der Suche automatisch gescrollt, und es wird auf das zu suchende Bild geklickt, viel einfacher geht es nicht mehr...

Da wird weder mit einem Disassembler rumgespielt, noch ist gewaltiger Code erforderlich.

Zitat von water

Korrigiere mich bitte, wenn ich das falsch sehe. Aber Betas werden doch released, damit die Benutzer testen und Fehler melden können bevor eine neue Stable rausgegeben wird. Wenn dann aber "keiner" (gestatte mir die Übertreibung - eigentlich sollten wir ja bei den Fakten bleiben ) testet, wessen "Schuld" ist das dann?

Ich korrigiere dich nicht, jeder darf seine Meinung haben und behalten.

Die Frage (und die Antwort darauf ist die Lösung des gesamten "Problems" !) ist, wieso "keiner" die über ein ganzes Jahr verteilten Betas getestet hat. Wahrscheinlich aus genau dem Grund, wieso ich auch nur sporadisch die Betas testete.
Runterladen, merken, dass damit einige Scripte nicht funktionieren, "neue Features" testen, diese für uninteressant befinden....vergessen...
Und das mehrmals im Jahr.
Ich denke, das bringt es auf den Punkt.

Mich würde mal interessieren mit welchem marketingtechnischen Hintergrund bspw. die "neuen" Features entwickelt wurden. Wurde eine Marktanalyse gemacht, welche die Notwendigkeit der Neuerungen unbedingt erforderlich machte? Hat mal jemand die weltweit 5 grössten AutoIt-Foren durchstöbert um herauszufinden, was der Otto-Normaluser wirklich braucht bzw. welche Probleme auf Anwenderseite in den Foren am häufigsten auftreten?
Ich weiss, wie hoch der Skill einiger der Entwickler ist. Wahrscheinlich so hoch, dass sie die "einfachen" Probleme der User garnicht nachvollziehen können. Das nennt man Betriebsblindheit, ein in der Branche extrem weit verbreitetes Problem. Da werden Lösungen gezaubert, für die es garkein Problem gibt....

Wenn man am oberen Ende der Fahnenstange angelangt ist, dann muss man sehr viel Aufwand betreiben, um nur sehr kleine Verbesserungen zu erreichen!

Zitat von nuts

Jeder Neuling, der mit MSDN arbeitet, denkt sich dann WTF? Was machen die denn da?

Was hat denn ein "Neuling" bei MSDN verloren?
Die gebräuchlichen Konstanten sind alle in AutoIt integriert, und keinesfalls sollen (lt. Konsens im blauen Forum) die "evil Numbers" verwendet werden!
Ein

while Guigetmsg()<>-3
wend

ist demnach "evil", aber gleichzeitig wird ein gigantischer programmiertechnischer Aufwand getrieben, um bspw. lange Funktionsnamen jetzt in 1-buchstabige Variablennamen pressen und somit "einfacher" verwenden zu können!

Zitat von water

wie schnell Valik mit einem solchen Herumgenöle abgefahren wäre.

Glaubst du ernsthaft, er hätte sich die Blöße gegeben in einer Woche 3 Stables abzuliefern? Ich nicht!
Er hätte sich auch eher die Hand abhacken lassen, als Konstanten zu ändern. Aber wenn das unbedingt hätte sein müssen, dann hätte er es auch stichhaltig begründen können
Und ja, er ist nicht (nur) aufgrund der Querelen im Forum gegangen.

Zitat von water

aber nur wenige User vom deutschen Forum sich an der Weiterentwicklung beteiligen.

Interessant, einige haben sich beteiligt. Daraufhin wurden Konstanten geändert. Aber hundertprozentig haben das "unsere" User nicht so gewollt! Dazu kenne ich sie zu gut

Nochmal, um das endgültig klar zu stellen:
Ich meckere nicht, weil irgendwelche "Weiterentwicklungen" nicht funktionieren. Das interessiert mich nicht.
Ich meckere, weil Scripte, die mit der 3.3.8.1 einwandfrei liefen, mit der 3.3.10.0 nicht mehr funktionieren.
Ich weiß auch, wieviel Arbeit in AutoIt steckt. Daher kann ich nicht nachvollziehen, wieso man erlaubt, dass diese Arbeit so einfach niedergemacht werden kann.
Ich habe nicht um eine neue Version gebettelt, so wie ich das sehe, wollten einige "Entwickler" aus welchen Gründen auch immer ( Profilneurose?! ) schnellstens eine neue Version releasen. Und das ist jetzt gründlich in die Hose gegangen.
Sich dann aber hinzustellen, und die "Schuld" den Anwendern zuzuschieben, die nicht fleissig genug gebetatestet haben, ist gelinde gesagt nur noch lächerlich.....

Zitat von minx

Noch etwas: Das Remove von PlugIns mit der Begründung niemand würde sie nutzen.

Wie kommen die darauf?
Die Plugins wurden entfernt, weil niemand der Entwicklergemeinde, also der DEV´s, sie nutzten.
Ich brauch es nicht, also brauchen es die anderen auch nicht.

Zitat

Edit: ein Lut in einer Programmiersprache ist allerdings "überlächerlich" (dafür fällt mir gar kein passendes Wort ein).

Macht eigentlich nur dann Sinn, wenn man Portabilität gewährleisten will. Also auf verschiedenen Systemen das definiert gleiche Ergebnis erhalten MUSS.
Aber idR kein Grund, ein "Tabellenbuch" als Code abzubilden. Juckt mich ehrlich gesagt auch nicht.
Zeigt aber wieder einmal, mit welchen programmiertechnischen Mitteln Code/Bugs gefixt werden, im Gegenzug aber "neue" Features reingedrückt werden (müssen). Irgendwie zieht mich das immer weiter runter

Zitat

Wenn ich zu anderen Sprachen größere Beispiele suche laufen die auch meistens nicht ohne weiteres, da in diesem Fall die verschiedenen Compiler, Versionen, seltsame Includes und sonstige Kunstgriffe ausschlaggebend sind.

Zitat

Wer Versionen 3.3.9.12 bis 3.3.9.23 hat, bitte melden!

Ist es jetzt soweit gekommen, dass man die maintenance.build-Nummern mit angeben muss, damit ein Script anstandslos läuft?!

//EDIT keine schlechte Idee wäre in diesem Zusammenhang ein "Online-Compiler", bei dem man die Versionsnummer auswählen kann. So könnte man sich auch bei "alten" Scripten den richtigen Compiler/Interpreter "ertesten"

3.3.8.1 (die letzte Stable) lief problemlos, Tweaky, bleib dabei^^

Ich habe kein Problem damit, dass man "unter der Oberfläche" optimiert um, wie Jon in einigen Threads erklärt hatte, AutoIt "clean" für die VC-Compiler zu machen. Sehe ich alles ein, auch dass es dabei zu Problemen kommen kann. Wenn das das interne Debugging vereinfacht, dann muss das eben sein. Ob AutoIt jetzt 5 oder 10% schneller läuft....wen juckt das wirklich?

Was ich nicht einsehe ist, dass "oben", also das was wir Anwender zu sehen bekommen, verändert wird. Neue Features hin oder her, wenn ich sie nicht brauche, dann muss ich sie auch nicht benutzen. Wenn aber "alte" Features unter den Füssen weggezogen werden, dann wird das komplette Konzept unbrauchbar.
Einige Dinge habe ich ja schon gefunden, wer sagt mir denn, dass nicht auch andere Funktionen, Konstanten, UDF´s usw. "optimiert" wurden?

Eine Stable heisst nicht umsonst so. Ich bin nicht Versionengeil. Wenn es 3 Jahre dauert, bis es wieder eine "gute" Version gibt, auch gut...aber eine Stable rauszubringen, damit jetzt fleissig das Betatesting vollzogen wird, welches anscheinend doch nicht sooo interessant für die allermeisten User gewesen ist, wirkt etwas angestrengt.
Wer geht davon aus, dass bei Scripten, die bei Alt-F5 nicht laufen, nicht ein Bug vorliegt, sondern ein Feature?

Es stellt sich mir sowieso die Frage, ob die "neuen" Features überhaupt für die Mehrzahl der AutoIt-Nutzer so immens wichtig waren?!

Das Problem sind nicht die Scripte auf meiner Platte, die kann ich automatisiert umbauen/ändern.
Viele online verfügbare Scripte laufen nicht oder bringen falsche Daten. Schade.

Zitat

Du kannst dich ja direkt im engl. Forum äußern und den Devs deine Meinung sagen

Habe ich. Nach einigem Hin und her bekam ich gesagt, ich solle doch besser kommerzielle Software für Anwendungen im professionellen Bereich verwenden (ich verwies darauf, dass ich AutoIt auch in der Firma einsetze)
Na dann, schreibe ich halt sämtliche für die Firma erstellten AutoIt-Scripte vorsorglich in VBA um, ist scheissaufwendig, ressourcenfressend und langsam, aber ich bin wenigstens sicher, dass die Programme auch in 6 Wochen noch laufen....wenn ein neues Windows rauskommt....

"Abwärtskompatibilität" ist definitiv mit den aktuellen AutoIt-Versionen gestorben. Ich muss Scripte mit der zum Zeitpunkt des Erstellens aktuellen AutoIt-Version kompilieren damit sie fehlerfrei laufen, und darf keinesfalls eine spätere Version verwenden?!

Wenn ich mir ansehe, was die POST-Valik-Ära hervorgebracht hat...
Wie war heute eine Antwort auf Crash-Potenzial bei Verwendung neuer Funktionen? "....If you do not want to use the new functionality then just do not use it ..."
Wenn ich die "new functionality" benutze bin ich selber schuld...na dann, viel Spass weiterhin.

Hi,
die "Lösung" mittels StringToBinary() ist imho alles andere als optimal!
Sämtliche Linefeeds und ggf. auch in Zukunft auftretende Sonderzeichen werden per StringToBinary() nicht entfernt, sie sind im String enthalten und werden sicher später noch zu Ärger führen....
Man sollte "fehlerhafte" Daten nicht durch das gesamte Programm schleppen, sondern sie direkt so aufbereiten, dass sämtliche weiteren Scriptteile damit einfach weiterarbeiten können.

Du hast nichteinmal selbst herausgefunden, dass dein String Zeichen enthält, mit denen einige AutoItfunktionen nicht klarkommen. Glaubst du etwa, dass andere Funktionen die "Sonderzeichen" in deinem String ignorieren?

Hi,
kurze Stringanalyse ermittelt Linefeeds chr(10) im Text, welche man mit StringStripWS entfernt

Zitat

Edit: sieht nicht so aus, als möchte man die Struct ändern, da nun sie der MSDN entspricht und jetzt richtig ist.

Wie die einzelnen Items der Struct benannt werden ist völlig UNERHEBLICH!
Was mich aber wirklich ankotzt ist die Tatsache, dass der KONSTANTEN-NAME $tagBITMAPINFO gleich geblieben ist!
Wer denkt sich denn solch einen Schwachsinn aus?
Das wäre, als wenn man "einfach so" GUI_EVENT_CLOSE von -3 auf 693 ändern würde....

WENN man schon die Struct mit allen ihren Items völlig umwirft, dann sollte man auch einfach einen anderen Namen vergeben. DAS ist richtig, und nicht einfach den Inhalt eines Strings verändern, nur weil bei MSDN die Structitems so heissen. (Was wie gesagt für die Funktion der Struct völlig unerheblich ist! )
Zzt. sind sämtliche Scripte, welche die "alte" Konstante tagBITMAPINFO verwenden, nicht mehr lauffähig. Soll ich nun in sämtlichen Scripten der letzten Jahre Konstanten (wieso heissen die wohl so? ) ersetzen bzw. überprüfen?

Zitat

In der Hilfe steht bei mir die richtige Beschreibung:

Ich vermute in der "neuen" Hilfe...
Die ist definitiv falsch, da eine KONSTANTE ihren Wert (Inhalt) per definitionem nicht ändert!