Beiträge von autoiter

@Musashi's Vorschlag würde ich hier ignorieren.

Schau dir einfach mal die Excel UDF an. Mit der Funktion _Excel_RangeRead kannst du sowohl einen Teilbereich auslesen (_Excel_RangeRead($oWorkbook, Default, "A1:C20") als auch einfach alle benutzten Felder (_Excel_RangeRead($oWorkbook, Default, $oWorkbook.ActiveSheet.Usedrange.Columns("A:A")) oder einfach alles _Excel_RangeRead($oWorkbook)....

Hi Bernd Albrecht,

Ok, du benutzt Funktionen bereits. Da gibt es dennoch viel Verbesserungspotenzial. Alleine, wenn du im Ursprungsskript nicht hundertmal eine Zelle ausliest, sondern einmal alles ausliest, wird dein Skript viel, viel schneller sein. Dann kannst du mit einem Array arbeiten - sowas wie das Ding, dass du als $aRanges definiert hast. Du kannst dann auf die einzelnen Array-Elemente in einer Schleife zugreifen und die an eine Funktion weitergeben, statt deine Funktionen mit x-Trillionen Paramatern zu füttern.

Dann solltest du dir überlegen, ob es Firefox sein muss. Für den alten IE gibt es eine UDF, die dir einige Dinge abnehmen würde. Statt einer statischen (unsicheren Wartezeit) könntest du auf die Bestätigung warten, dass eine Seite geladen ist usw.

Alberner Quatsch. Das ist ein Botter.

Hi Bernd Albrecht

Funktionen - dein täglich Brot. Nimm dir mal kurz Zeit, die auch in deutsch verfügbare Hilfe anzusehen. Dort gibt es in den ersten Kapiteln auch eine Einführung, die du dir ansehen solltest - sonst machst du einfach viel Quatsch).

Ist kein guter Stil. Also eigentlich nix für größere Projekte. Aber wenn du eine Funktion mal so und mal so nutzen willst, also vllt. einmal einen Bereich auslassen möchtest, könntest du eine Funktion mit einem Boolean (wahr-falsch) als optionalen Parameter aufrufen.

_SchreibeBlock("erste")
_SchreibeBlock("zweite")
_SchreibeBlock("dritte")
_SchreibeBlock("vierte")
_SchreibeBlock("fünfte")
_SchreibeBlock("", True)

Func _SchreibeBlock($sText, $bExtraAusgabe = False)
    ConsoleWrite(" -----------------------------------------" & @CRLF)
    ConsoleWrite(" Dies ist der " & $sText & " Block " & @CRLF)
    ConsoleWrite(" -----------------------------------------" & @CRLF)
    If $bExtraAusgabe then
        ConsoleWrite("Ende der Geschicht" & @CRLF)
    EndIf
EndFunc

Hi Bitnugger ich weiß nicht ob das ressourcenschonender ist, aber statt so einem Code, den wohl niemand nutzen würde, wäre es vllt. besser allgemein die Nutzung von ControlClick oder ControlSend vorzuschlagen.

EDIT: Jo water das habe ich auch gedacht. Ich hätte gar nichts geschrieben, wenn dein Kommentar schon sichtbar gewesen wäre.

Ja, so Fehler passieren schonmal im Eifer des Gefechts.

Aber danke für den Hinweis. Ich meine, es steht natürlich klar in der Hilfe. Aber ich habe das gar nicht auf dem Schirm gehabt (-scheinbar noch nie auf einen ganzen Text angewendet). Aber das etwa aus crlf cr wird sollte man auf dem Schirm haben.

Stimmt

Sorry, die Demo aus deinem ersten Beitrag ist bei mir nicht ausführbar.AutoIt3.exe ended.rc:-1073741571

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.

Hi Professor Bernd

Ich weiß nicht, wie du das StringReplace umgesetzt hast (muss aber langsamer sein als StringStripWS). Aber die String Funktionen selbst sind eigentlich alle sehr schnell. Da würde ich nicht viel überlegen.

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

Zitat von Andy

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.