Ich denk bei ANSI immer an ASCII.
Trotzdem sollte es nicht funktionieren, da ja der Umlaut mit zwei Bytes dargestellt wird, in ANSI ist aber nur ein Byte notwendig.
StringToBinary wandelt mit dem Standardflag ANSI (1) um, d.h. damit deine Variante funktioniert, hättest du den String mit UTF-8 (4) konvertieren müssen,
aber auch das klappt nicht, weil ja zwei separate Zeichen vorhanden sind und kein Umlaut.
Das Flag am Ende kommt nicht hin, nimm UTF-8 (4) denn Umlaute gibt es im ANSI (1) nicht.
Du musst das Array durchlaufen und den Inhalt des Indexes einfach mit der Umwandlung ersetzen, du brauchst kein neues Array zu erzeugen.
Ich wollte deinen Code sehen um die Fehler ausmachen zu können, nicht die Fehlermeldung.
Die Zeilennummer ist schon richtig, denn sie ist die finale Nummer nachdem alle Includes eingefügt wurden.
Nimm den Au3Stripper der beim Compiler-Wrapper enthalten ist und führe ihn mit wenigen Parametern aus, so dass er einfach nur das Skript kompiliert aber die Includes reinfügt, dazu gabs sogar letztens einen Thread hier.
Deine Zeilenfehlermeldung ist in der *_stripped.au3 dann korrekt.
Wie sollen wir dir denn helfen wenn du uns nicht mal einen Codeschnipsel postest?
Was hältst du davon eine Variable mit dem Zähler zu speichern und zu prüfen ob der Dateiname mit dem Zähler schon existiert? Wenn das der Fall ist kannst du den ja einfach erhöhen und nochmal nachprüfen.
Überprüf doch vorher ob der neue Dateiname existiert, und wenn dies der Fall ist nimmst du einfach ein _1 hinten dran.
Das ist ziemlich eigenartig, dass er die Elemente nicht findet auch nach dem zwei Sekunden Sleep.
Wird die Seite denn im aktuellen Tab geladen? Ensteht ein neues Fenster?
Wird der Code der nicht funktioniert direkt ausgeführt oder erst wenn die Seite fertig geladen ist?
Liegen die Elemente auf die du zugreifen möchtest in einem <iframe>?
vielen Dank für deine Antwort. Hattest du den Code im Spoiler gesehen?
Ups, das hab ich wohl übersehen.
Probiers mal mit $oInput = _IEGetObjById($oIE, "e") und dann _IEFormElementSetValue($oInput, "blablubb").
Im Übrigen brauchst du nicht explizit die Form selbst zu holen, sondern kannst die enthaltenen Elemente direkt referenzieren.
Nimm dazu einfach _IEGetObjByName oder _IEGetObjById auf das $oIE Objekt.
Aber könntest du mir bitte netterweise aufzeigen wie ich es trennen muss ?
Das hab ich doch getan.
Du hast nur eine Zeile in der du versuchst mehrere Variablen gleichzeitig Werte zuzuweisen, weise stattdessen einfach in jeder Zeile eine Variable einzeln zu und dann klappt das auch.
Danke fürs Posten der Fehlermeldung, sehr hilfreich.
AutoIt erlaubt keine mehrfachen Definitionen innerhalb einer Zeile wenn kein Scope mitgeliefert ist um die Variablen gleich zu deklarieren.
Trenn die Zeilen auf oder setz das Scope davor.
Aber ich bekomme es nicht hin. Ich rate da wild herum, weil ich auch keine Ahnung von html habe.
Der Weg führt nicht nach Rom.
Es handelt sich um eine ganz einfache firmeninterne Website.
Wenn du die sensiblen Firmendaten streichst und mal den Bereich isolierst auf den du in der HTML zugreifen möchtest können wir dir besser helfen, denn so können wir nur spekulieren.
Wichtig ist, dass du die Tag-Reihenfolge behalten solltest, wir müssen wissen ob Elemente in iframes liegen oder nicht.
Versuch mal mit _IEGetObjByName auf das Element zuzugreifen statt der Form, vielleicht klappt es ja damit.
Dein Code kann so nicht funktionieren, da die Form nicht erneuerst wenn du die Seite gewechselt hast, also wird der Teil mit ; ### AB hier funktioniert es nicht. sowieso nicht laufen können.
Ich bin mir nicht sicher ob ich mich irre aber die Kosten sind rekursiv einfach zu ermitteln Kosten(Stufe) = Kosten(Stufe - 1) + Kosten(Stufe - 1) oder auch 2^(Stufe-1).
Wenn man auf Stufe 10 kommen möchte braucht man 512 verschiedene Kugeln.
Ich war in Kombinatorik/Diskrete Strukturen nicht der beste, aber der Weg schien mir plausibel.
For $i = 1 To 10
ConsoleWrite("Kosten um von Stufe 0 auf Stufe " & $i & " zu gelangen: " & KostenErmitteln($i) & @CRLF)
Next
Func KostenErmitteln($NeueStufe)
If $NeueStufe = 1 Then Return 1
Return KostenErmitteln($NeueStufe - 1) + KostenErmitteln($NeueStufe - 1)
EndFuncDie Regeln sind mir da bisschen zu schwammig definiert, keiner hat gesagt, dass ich bei Stufe 1 starten muss oder ob ich bestehende Türme auflösen darf.
Deaktivier das Redrawing der ListView mal während du sortierst, dadurch sollte es ein wenig flotter sein.
_GUICtrlListView_BeginUpdate / EndUpdate
Das finde ich anmaßend und unverschämt! Ich hoffe, das war nicht so gemeint!?
Doch genau so war es gemeint, und ich glaube ich liege damit auch richtig. Nicht jeder weiß was in einem AV-Programm abgeht. Du hättest doch den Thread nicht aufgemacht wenn du davon bescheid gewusst hättest?
Der Tonfall mag sich vielleicht herablassend oder arrogant angehört haben, aber so sollte es nicht rüberkommen. Habe da keine Lust um den heißen Brei herumzureden sondern komm gleich direkt zum Thema.
So nun auch zu Tuxedos Stellungnahme, es mag sich frech anhören aber lies die Zeilen einfach nochmal:
Das einzige Forum wo man immens etwas lernen konnte war das alte Forum von Wambo
oder auch noch epvp.
Was denn lernen? Wie man Bots und 0815-Hacks schreibt? Anders sind die nicht in meinem Gedächtnis hängengeblieben, ich mag mich auch irren.
Dafür, dass wir hier den Skriptkiddiebodensatz so gut wie möglich auszusieben versuchen sind hier tolle Projekte und Tutorials entstanden die sich sehen lassen können.
Dass die Leute irgendwann das Interesse an AutoIt verlieren und sich anderen Themen widmen ist einfach der Lauf der Dinge.
Da konnte man in einem Monat mehr lernen als hier in einem ganzen Jahr.
//Edit: Dass ein User nicht die Motivation mitbringt sich mit dem Thema richtigauseinander zu setzen und lieber fertige Lösungen/Lösungsansätze kopiert statt in der Doku die Funktionen mal richtig anzuschauen sehe ich nicht als lernen.
"Spoonfeeding" ist nicht mit Lernen gleichzusetzen. Wenn sich jemand die Mühe macht mal einen Tag zu lernen wie man effektiv unbekannte Probleme löst und die Dokumentation verwendet, bräuchte es 70% der Threads nicht.
Wenn es ein vernünftiger richtiger Compiler wäre, dann hätte nicht jede EXE den
gleichen Aufbau(wo mindestens 60% der EXE den selben Code aufweist),
dann wären es mit Sicherheit nur noch wenige Ausnahmen von False-Positives und der Rest der gemeldeten
EXEN wären dann tatsächlich verseuchte Dinger.
Hätte sie das tatsächlich nicht? Was ist denn mit den UDFs die zuhauf includet werden, werden die bei jedem neuen Kompilat denn anders in die Exe eingebunden?
Sollten die Compilermethoden auch als False-Positive erkannt werden würde ein Kompilat verglichen mit Interpreter und Skript überhaupt nichts ändern.
Warum auch? Der Compiler arbeitet doch immer identisch und wird Konstrukte wie Hello, world! oder andere Routinen immer gleich abbilden (nur ist es halt Bytecode der erkannt wird, statt dem Skript oder der Interpreterbytecode)
Landet ein False-Positive in der Datenbank, ist der Rest automatisch verdächtig.
Aber zum Compilerthema kommen wir jetzt:
Abgesehen davon hätte ein richtiger Compiler noch andere positive Seiten:
Leichte Decompilierbarkeit wäre nicht mehr gegeben,
und die Programme hätten nur noch rund 1/20 der Grösse.
Programmspeed wäre auch um einiges höher.
Andy hätte hier sicherlich noch mehr Positives auf Lager.
Na das klingt doch alles super! Dann schüttel dir doch einen Compiler aus dem Arm... ist nicht oder?
Die Sprache könnte einige Funktionen nicht bieten (zumindest nicht so einfach wie bei der interpretierten Variante), wenn sie compilen würde.
Außerdem wäre der Aufwand auch dementsprechend höher, da neue Konstrukte tief in den bestehenden Quellcode eingreifen und der Compiler dafür optimiert werden muss.
Bei der Interpretation ist das nicht ganz der Fall, so kann man neue Konstrukte anhängen ohne sich die selben Sorgen machen zu müssen.
Leichte Dekompilierbarkeit sollte man von der Seite mal betrachten:
Würden sich die Devs von AutoIt3 wirklich die Sorgen darum machen, hätten sie in den Teil wesentlich mehr Zeit und Energie reingesteckt als es im Moment der Fall ist.
AutoIt ist auch nicht dafür gemacht worden eigenständige Programme zu schreiben, aber jeder "missbraucht" es dafür, weils Spaß macht, einfach ist und funktioniert (liest du bestimmt auch grad in der SB)
Das Argument mit der Größe kannst du vielleicht vor dem Jahr 2000 bringen, aber heutzutage nicht mehr. Eine 800 KB exe stört wahrlich niemanden der auf Windows arbeitet.
Wir sind hier nicht in embedded Bereich wo jedes Kilobyte an Speicher und RAM zählen. Bei Sprachen die für sowas eingesetzt werden (wo es auf Performanz und Speicher ankommt) kannst du das Argument gerne bringen, da funktioniert es.
Das Argument mit dem Programmspeed ist vom selben Schlag. AutoIt stellt nicht den Anspruch eine Programmiersprache zu sein und ist deshalb auch nicht auf Geschwindigkeit ausgelegt.
So schnell wie es im Moment läuft ist es mehr als ausreichend für den Aufgabenbereich wofür es konzipiert worden ist.
Oftmals ist der Code des Users einfach schlecht wenn es an Geschwindigkeit mangelt, und sollte man wirklich flotte Berechnung in kleinen Loops wollen kann man ASM Code callen (was übriges ein nettes Feature ist, was nicht in der Orignalidee enthalten war).
Compiler, sofern die Zeit und Ressourcen gegeben sind, sticht in jedem Fall einen Interpreter aus, das sollte auch niemanden überraschen, aber der Aufwand ist enorm.
Ich lese deine Zeilen so (auch wenn es 100%ig nicht so gemeint ist), als ob die Devs damals einfach eine Münze geschmissen haben und dachten "ja lol was solls, machen wir halt interpreter".
Wozu soll man für eine Skriptsprache die Win32-Controls automatisieren soll einen Compiler schreiben? Das ist doch Blödsinn.
Aber auf so einen Compiler werden wir wohl noch bis ans Ende der Tage warten dürfen.
So wie die Autoit-Entwickler arbeiten, mit dem anhaltenden Blödsinn ständig bestehende gut funktionierende
Funktionen einfach ohne Grund zu verändern oder Parameter-Anzahl+Art oder Reihenfolge zu ändern ohne,
daß dies notwendig wäre, müssten sie den Compiler bei jeder neuen Version nicht nur erweitern sondern
jedesmal den halben Compiler um oder neuschreiben.
Nicht nur auf den Compiler darfst du lange warten, sondern auch auf die nächste Evolutionsstufe.
Wenn Win32-Controls erstmal komplett vom Markt sind (das wird noch ein paar Jahre/Jahrzehnte dauern, auf dem Serverbereich/Arbeitsbereich gibt es ja noch immer alte Programme die nach wie vor genutzt werden, und das aus mehreren Gründen), ist AutoIt weg vom Fenster wenn es nicht grundsätzlich umgearbeitet wird.
Ich hatte dazu in der SB mal gepostet, ob wir nicht einen WPF-Wrapper schreiben wollen um die neuen Controls zu unterstützen, aber das ist eine Megaaufgabe die viele Leute und gute Planung benötigt.
"Die AutoIt-Entwickler"? Meines Wissens nach sitzt da nur noch Jon dahinter, und auch der scheint irgendwie die Nase voll zu haben.
AutoIt hat sich schon seit einigen Versionen in Sachen Funktionen, Parameter und UDFs verrannt und daraus wird es keinen Ausweg geben wenn es keinen (beinahe vollständigen) Rewrite gibt.
Aber ich würde mich gerne über ein paar Beispiele freuen, scheinbar hast du ja welche, ich hab grad keine auf dem Schirm (was die Veränderungen "ohne Grund" und "Parameter-Anzahl+Art" etc. betrifft).
Wenn dir ein paar einfallen schick sie mir doch bitte.
Sende das als Virus erkannte/gelöschte "Hello Wordl!" an den AV Hersteller und sag ihm, dass dies ein false-positive ist. Die prüfen dann nochmals genauer und nehmen es wieder aus der Signatur-DB heraus. Ist aufwändig und uU mehrmals zu wiederholen.
Die Mailadressen der AV-Hersteller sind auch im engl. Thread verlinkt.
Stimmt, das hatte ich auch im Hinterkopf aber beim Entwickeln von Skripten ist das noch nicht zu gebrauchen, erst wenn man das ganze kompiliert bzw. releasefertig ist.
Dann kann man das ganze einschicken und whitelisten lassen.
Wie soll "MsgBox(0, "", "Hallo Welt!") eine "schwerwiegenden Bedrohung" auslösen!?
Ich würde es ja gerne testen, aber Defender löscht scheinbar willkürlich.
Das liegt daran, dass du keine Ahnung davon hast wie Antivirensoftware funktioniert. Die tatsächlichen Algorithmen, Fingerprints und Datensätze sind zwar immer unterschiedlich von AV-Anbieter zu AV-Anbieter aber im Grunde ist es immer dasselbe Spiel:
Exe wird geprüft ob sie eine bestimmte Signatur hat (kommen bestimmte Codepfade vor, greift sie auf sensible Daten zu, ...) und wenn das übereinstimmt wird sie als Virus erkannt.
Wenn nun eine Datenbank mit False-Positives gepflastert sind werden scheinbar willkürlich Skripte gelöscht die aber nicht böse sind, das kann das AV-Programm aber nicht wissen, wenn es das täte würde ein Virendefinitionsupdate mehrere Terabyte groß sein.
Im Grunde hast du keine zufriedenstellende Lösung des Problems, nur ein paar Ausflüchte (die mir spontan einfallen):
Das ngc.bmp Bild ist inkompatibel, deine Benennung der wii.bmp ist in der Ini falsch (es müsste wii.bmp nicht nwii.bmp heißen) und du läufst vom Index 1 bis nach [0] - 1 obwohl [0] den letzten Index beinhaltet.
Bitte, danke.
Ist UPX da als Standard ein- oder ausgeschaltet?
Das sollte ausgeschaltet sein. Einfach auf die Dateigröße schauen, ohne UPX sind die Dateien bereits ohne Skript bei 800KB+ mit UPX grade mal bei der Hälfte.
