Beiträge von autoiter
-
-
Hallo Leute, hallo Mars
Freut mich, dass du oft schneller in C++ bist als in Autoit. Für die meisten realen Anwendungsfälle halte ich das für mich völlig unerreichbar. Allerdings habe ich auch nur mal eine Vorlesung C++ besucht und sonst nichts damit gemacht. Wer weiß, was ein echter Könner zaubern kann.Auch in AutoIt warst du wahrscheinlich vor zehn Jahren schon besser als ich. Daher ist das zwar ein Kommentar, der etwas Zweifel ausdücken soll, aber nicht sarkastisch gemeint ist.
Für die allermeisten (auch guten Programmierer) wird eine Sprache wie AutoIt schnellere Lösungen bieten. Daher hat sie ganz sicher ihre Berechtigung.
Deine Wünsche teile ich aber alle überhaupt nicht. Überladung von Funktionen, naja ok. Überladung von Operatoren? Das macht für mich irgendwie alles kaputt für das AutoIt steht.
Ich folge völlig alpines. AutoIt sollte in erster Linie Probleme der Automatisierung vereinfachen.Genau am Kern-Feature verliert AutoIt gerade. Stattdessen werden Sachen gewünscht, die mit der einfachen Automatisierung gar nichts zu tun haben, sondern auf mittlere Sicht, das Niveau heben und es Einsteigern schwerer machen.
Man hat doch eine ganze Fülle von Sprachen, die bieten was du möchtest. Aber ist es wirklich der richtige Weg für AutoIt? Denk mal an deinen Einstieg in die Programmiersprache zurück. Hätten diese Konzepte den krass einfachen Einstieg in die Programmierung geboten, gefördert oder behindert?
In erster Linie war die Sprache gedacht, schneller umsetzbare Lösung im Automatisierungsbereich zu ermöglichen.
Klar, kann man mit der Sprache noch viel mehr machen. Die Hilfe zeigt es. Viele hier haben das bewiesen - auch du.
Aber der Kern der Sprache ist Automatisierung. Man kann sich nun dafür einsetzen, dass AutoIt Dinge kann, die in anderen Sprachen schon viel besser funktionieren oder man kümmert sich darum, dass die Stärken von AutoIt nicht verloren gehen.
Ich halte letzteres für sinnvoller.
Mars ich hoffe das kommt nicht als negativer Angriff rüber. Ich habe einfach einen ganz anderen Blick auf die Sprache und wollte den Unterschied hier deutlich machen. -
-
Habs ausprobiert. Beim Update läufts.
-
Versteh ich. Für den oben genannten Zweck bleibt es aber auch so ein sehr beachtenswertes Skript.
-
Hi HansJ54
Wie beschrieben ist der Base64-Generator der absolute Standard für die Aufgabe einfach super kompfortabel. Schau dir für Beispiele auch mal den Release im EN Forum an. Dort liefert UEZ gleich selbst ein paar tolle Anwendungsbeispiele: https://www.autoitscript.com/forum/topic/13…r-files-easily/
Was du dir auch ansehen solltest ist sein AutoIt Sysinternal Tools Synchronizer. Beim Ausprobieren eben gesehen, dass die Anzeige der Programme scheinbar nicht mehr funkioniert UEZ Aber da kannst du dir mal ansehen, wie du so ein Programm allgemein durchstylen kannst. -
Hallo Leute,
ich denke mein Problem hat sich erledigt.
Liest sich für mich, als wäre das der Legacy CryptoAPI Codec, der rausgeschmissen wurde.
https://system.data.sqlite.org/index.html/doc/trunk/www/news.wiki -
Hallo Leute,
kennt sich jemand von euch mit der System.Data.SQLite.dll aus?
Ich wollte eine SQLite Db, die dauerhaft auf einem fremden System liegt mit einem Passwort versehen. Dazu wollte ich die System.Data.SQLite.dll benutzen.
Vor einiger Zeit hatte ich das schon zur Zufriedenheit getestet. Gestern habe ich das erneut auf einem anderen versucht Rechner und es ging nicht mehr. Nach einem Check auf dem anderen Rechner konnte ich nur feststellen, dass ich zuerst Version 1.0.112.0 benutzt habe und später Version 1.0.113.0 (jeweils sqlite-netFx46-static-binary-bundle-Win32-2015-1.0.112.0).
Scheinbar funktioniert in Version 1.0.113.0 Pragma key nicht mehr oder anders. Allerdings konnte ich dazu nichts finden.
Im Anhang habe ich mal die beiden dlls und ein Testskript. Es wird jeweils einmal mit Passwort in eine Db geschrieben und ausgelesen. Im Anschluss wird das Auslesen ohne Passwort versucht. Bei Version 1.0.113.0 klappt das leider..
-
Haha, danke Bitnugger
und ich schwadroniere was von undokummentiert.
Bitte schüttelt mich, wenn ich noch wirrer werde und irgendwas fasele wie Corona ist eine Erfindung, um die 5G-Toten zu verheimlichen.
-
Hallo Professor Bernd
Eine der wenigen Textstellen, die du nicht zitiert hast, halte ich schon für eine Lösung
Und weil nicht die Frage ist, ob mein AutoIt-Script einen Virus enthält, sondern ob das AV-Programm einen Virus erkennt, habe ich auch absolut kein Problem damit den Anwender/Arbeitgeber mit der Frage zu konfrontieren, ob er mir mehr vertraut als dem AV-Programmhersteller.
-
Ich kenne _ReadExcel() auch nicht. Aber an dem Phänomen, bin ich auch schon kläglich gescheitert.
Genau wie du schreibst ist das Problem die (für neuere Office Versionen undokummentierte) Anzahl der Buchstaben pro Zelle, wenn du die COM Schnittstelle benutzt.
Wenn man die (Standard) Excel UDF von Water benutzt, findet man aber auch recht schnell einen Hinweis https://www.autoitscript.com/wiki/Excel_UDF#Script_crashes -
Haha, ich war kaum fertig, da kam der bessere Vorschlag
Ist etwas weird jedesmal fixe Daten auf die Platte zu legen, aber wenn es mit einem simplen Parameter geht, ist das sicher die einfachste Lösung.
-
Ah, ok.
Meist sind solche Daten Einzeiler. Wenn du aber wirklich so viele Daten hast, könntest du deine Daten auch als #include einbinden. Dann werden sie erst zur Laufzeit/beim Kompilieren eingebunden und stören dich nicht bei der Entwicklung. Jedenfalls würde ich so vorgehen. (Sofern wir nicht von 100k+ Daten sprechen. Dann würde ich eine Datenbank vorschlagen, die erst durchsucht wird um dann die Combobox mit den Ergebnissen zu füllen). Vielleicht gibt es aber noch bessere Vorschläge.
-
Hallo Sirius
Das ist witzig
Eine ini-Datei ist für die Speicherung von sich ändernden Einstellungen da - wie etwa die letzte Fensterposition. Wenn du feste Werte hast, die sich nicht ändern sollen, schreib die in den Quelltext, wo sie hingehören.
Ich nehme aber mal an, das ist dir klar und du hast dich nur etwas unglücklich ausgedrückt, oder? Dann leg bitte nochmal einmal nach -
Hallo SCCSSF
Schau dir mal die Hilfen zu ControlSend und Send an. Bei Send ist beschrieben, wie man bestimmte Steuerzeichen escaped.
-
Hi Oscar
Ich verstehe dich. Aus meiner Sicht, bist du meiner Ausführung aber nicht zu Ende gefolgt.
Du willst ein Programm erstellen, dass es absoluten Laien, die außer der Google-Leiste im Browser schon nichts finden, eine Antivirensoftware bereitstellen.
Braucht mir keiner erklären, dass hier schon der Fehler liegt. Ist aber im Bsp gegeben.
Jetzt ist Interpreter-Software ja genau zu prüfen. Nach dem "Kompilieren" kommt ja kein Maschinencode raus..
Das heißt doch, man müsste JEDE dieser Sprachen SEHR genau kennen, um Risiken auszuschließen. Oder man müsste aufwendig Testumgebungen für alles bereitstellen, oder nicht?
Ich würde dann selbst den Rotstift bei Sprachen ansetzen, die in der Vergangenheit negativ aufgefallen sind und ganz blind for einer möglichen Bedrohung warnen.Da würde ich das größte Potenzial für uns sehen. Die meisten Scanner schlagen ja gar nicht aufgrund irgendeiner Blacklist gegen den AutoIt-Interpreter an. Ihre Heuristik kommt zu dem Schluss, hier KÖNNTE eine Bedrohung vorliegen.
Wenn ihr was machen wollt, würde ich bei den AVs nachfragen, ob man nicht die Meldung klarer machen könnte."Wir haben nichts gefunden, aber es könnte sein, dass dieses Programm schädlich ist!"
Wenn da die Antwort Quatsch und ablehnend ist, würde ich mich an einem Shitstorm beteiligen. Wir würden sicher viele Teilnehmer finden. Allerdings kann es auch sein, dass wir gegen die Antwort nicht viel anderes sagen können als, "aber wir sind doch nicht böse!!!1!11". Damit wäre ich dann raus..
-
// Reine Meinungsäußerung
Außerhalb des administrativen Bereichs ist AutoIt3(!) einfach sehr oft für negative Zwecke genutzt worden. Ich wäre froh, wenn die AVs sich wenigstens den Code ansehen würden und testen würden, ob die Option (Option Leute!!!) gesetzt ist: pragma compile(AutoItExecuteAllowed, False). Wenn dann noch UPX nicht genutzt wird, sollte einer Überprüfung nichts im Wege stehen. Nichts?
Wohl eher nicht, fürchte ich. Ich scheitere jedenfalls an dem Gedankenexperiment mir vorzustellen, wie der Prozess für ein perfektes AV aussehen sollte. Erleuchtet mich bitte, wenn ihr das besser wisst.
Kann ich sicher davon ausgehen, dass ein Interpreter-Skript keinen Code nachlädt?
Kann ich mittels Tests ausschließen, dass Schadcode während der Laufzeit gebildet wird?
Kann ich für tausende, immer neue Programmiersprachen solche Tests entwickeln?Sind meine Tests sicher?
Wenn ich einer Omi nicht garantieren kann, dass mein AV jede Schadsoftware erkennt, wie gehe ich dann vor?
Egal welche Parameter und Gewichtungen ich vornehme.. Bei der Historie von AutoIt kann ich mir nicht vorstellen, dass Software in dieser Programmiersprache bei mir ohne ausufernde, nicht rentable Tests auf eine Whitelist käme.
Man kann sich bei den AV Herstellern melden und versuchen, seine Software kostenlos "whitelisten" zu lassen. Mehr ist wohl nicht drin. -
Hallo Silvermoon1
(nenn dich besser 2 wenn du nicht der erste bist )EDIT : Alternativ -> file-to-base64-string-code-generator von UEZ
Dieser Hinweis von Musashi ist wirklich die beste Methode für eigene Bilder.
-
Sorry Oscar , natürlich ist das Mist.
Mit allem anderen rennt man aber gegen die Wand.
Wir können uns die Welt nicht selbst stricken und müssen akzeptieren, dass AutoIt in absehbarer Zukunft keine Sprache ist, in der man tolle Applikationen zum freien Teilen erstellen kann.
Meiner Erfahrung nach machen Enterprise Virenscanner kein Gewese um AutoIt. Es ist für Administratoren (meine ich) kein Problem.
-